Cloud Solution Architect

MicrosoftOfficialPublished by Microsoft

Skill
Guidelines
Software development
MIT
No issues found

From the author

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.

— the description by Microsoft

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://mp-staging.autogineer.com/agent-skills/microsoft/cloud-solution-architect/download

Unzip 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 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

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/design-principles.md

Azure Design Principles

Ten principles for building reliable, scalable, and manageable applications on Azure.

#	Principle	Focus
1	Design for self-healing	Resilience & automatic recovery
2	Make all things redundant	Eliminate single points of failure
3	Minimize coordination	Scalability through decoupling
4	Design to scale out	Horizontal scaling
5	Partition around limits	Overcome service boundaries
6	Design for operations	Observability & automation
7	Use managed services	Reduce operational burden
8	Use an identity service	Centralized identity & access
9	Design for evolution	Change-friendly architecture
10	Build for the needs of business	Align tech to business goals

1. Design for self-healing

Design the application to detect failures, respond gracefully, and recover automatically without manual intervention.

Recommendations

Implement retry logic with backoff for transient failures in network calls, database connections, and external service interactions.
Use health endpoint monitoring to expose liveness and readiness probes so orchestrators and load balancers can route traffic away from unhealthy instances.
Apply circuit breaker patterns to prevent cascading failures — stop calling a failing dependency and allow it time to recover.
Degrade gracefully by serving reduced functionality (cached data, default responses) rather than failing entirely when a dependency is unavailable.
Adopt chaos engineering with Azure Chaos Studio to proactively inject faults and validate recovery paths before real incidents occur.

Pattern	Purpose
Retry	Handle transient faults by transparently retrying failed operations
Circuit Breaker	Prevent repeated calls to a failing service
Bulkhead	Isolate failures so one component doesn't take down others
Health Endpoint Monitoring	Expose health checks for load balancers and orchestrators
Leader Election	Coordinate distributed instances by electing a leader
Throttling	Control resource consumption by limiting request rates

Azure services

Azure Chaos Studio — fault injection and chaos experiments
Azure Monitor / Application Insights — health monitoring, alerting, diagnostics
Azure Traffic Manager / Front Door — DNS and global failover
Availability Zones — zonal redundancy within a region

2. Make all things redundant

Build redundancy into the application at every layer to avoid single points of failure. Composite availability formula: 1 - (1 - A)^N where A is the availability of a single instance and N is the number of instances.

Recommendations

Place VMs behind a load balancer and deploy multiple instances to ensure requests can be served even if one instance fails.
Replicate databases using read replicas, active geo-replication, or multi-region write to protect data and maintain read performance during outages.
Use multi-zone and multi-region deployments to survive datacenter and regional failures — define clear RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets.
Partition workloads for availability so that a failure in one partition doesn't affect others.
Design for automatic failover with health probes and traffic routing that redirects users without manual intervention.

Pattern	Purpose
Deployment Stamps	Deploy independent, identical copies of infrastructure
Geode	Deploy backend services across geographies
Health Endpoint Monitoring	Detect unhealthy instances for failover
Queue-Based Load Leveling	Buffer requests to smooth demand spikes

Azure services

Azure Load Balancer / Application Gateway — distribute traffic across instances
Azure SQL geo-replication / Cosmos DB multi-region — database redundancy
Availability Zones — zonal redundancy within a region
Azure Site Recovery — disaster recovery orchestration
Azure Front Door — global load balancing with automatic failover

3. Minimize coordination

Minimize coordination between application services to achieve scalability. Tightly coupled services that require synchronous calls create bottlenecks and reduce availability.

Recommendations

Embrace eventual consistency instead of requiring strong consistency across services — accept that data may be temporarily out of sync.
Use domain events and asynchronous messaging to decouple producers and consumers so they can operate independently.
Consider CQRS (Command Query Responsibility Segregation) to separate read and write workloads with independently optimized stores.
Design idempotent operations so messages can be safely retried or delivered more than once without unintended side effects.
Use optimistic concurrency with version tokens or ETags instead of pessimistic locks that create coordination bottlenecks.

Pattern	Purpose
CQRS	Separate reads from writes for independent scaling
Event Sourcing	Capture all changes as an immutable sequence of events
Saga	Manage distributed transactions without two-phase commit
Asynchronous Request-Reply	Decouple request and response across services
Competing Consumers	Process messages in parallel across multiple consumers

Azure services

Azure Service Bus — reliable enterprise messaging with queues and topics
Azure Event Grid — event-driven routing at scale
Azure Event Hubs — high-throughput event streaming
Azure Cosmos DB — tunable consistency levels (eventual to strong)

4. Design to scale out

Design the application so it can scale horizontally by adding or removing instances, rather than scaling up to larger hardware.

Recommendations

Avoid instance stickiness and session affinity — store session state externally (Redis, database) so any instance can handle any request.
Identify and resolve bottlenecks that prevent horizontal scaling, such as shared databases, monolithic components, or stateful in-memory caches.
Decompose workloads into discrete services that can be scaled independently based on their specific demand profiles.
Use autoscaling based on live metrics (CPU, queue depth, request latency) rather than fixed schedules to match capacity to real demand.
Design for scale-in — handle instance removal gracefully with connection draining and proper shutdown hooks.

Pattern	Purpose
Competing Consumers	Distribute work across multiple consumers
Sharding	Distribute data across partitions for parallel processing
Deployment Stamps	Scale by deploying additional independent stamps
Static Content Hosting	Offload static assets to reduce compute load
Throttling	Protect the system from overload during scale events

Azure services

Azure Virtual Machine Scale Sets — autoscale VM pools
Azure App Service / Azure Functions — built-in autoscale
Azure Kubernetes Service (AKS) — horizontal pod autoscaler and cluster autoscaler
Azure Cache for Redis — externalize session state
Azure CDN / Front Door — offload static content delivery

5. Partition around limits

Use partitioning to work around database, network, and compute limits. Every Azure service has limits — partitioning allows you to scale beyond them.

Recommendations

Partition databases horizontally (sharding), vertically (splitting columns), or functionally (by bounded context) to distribute load and storage.
Design partition keys to avoid hotspots — choose keys that distribute data and traffic evenly across partitions.
Partition at different levels — database, queue, network, and compute — to address bottlenecks wherever they occur.
Understand service-specific limits for throughput, connections, storage, and request rates and design partitioning strategies accordingly.

Pattern	Purpose
Sharding	Distribute data across multiple databases or partitions
Priority Queue	Process high-priority work before lower-priority work
Queue-Based Load Leveling	Buffer writes to smooth spikes
Valet Key	Grant limited direct access to resources

Azure services

Azure Cosmos DB — automatic partitioning with configurable partition keys
Azure SQL Elastic Pools — manage and scale multiple databases
Azure Storage — table, blob, and queue partitioning
Azure Service Bus — partitioned queues and topics

6. Design for operations

Design the application so that the operations team has the tools they need to monitor, diagnose, and manage it in production.

Recommendations

Instrument everything with structured logging, distributed tracing, and metrics to make the system observable from day one.
Use distributed tracing with correlation IDs that flow across service boundaries to diagnose issues in microservices architectures.
Automate operational tasks — deployments, scaling, failover, and routine maintenance should require no manual steps.
Treat configuration as code — store all environment configuration in version control and deploy it through the same CI/CD pipelines as application code.
Implement dashboards and alerts that surface actionable information, not just raw data, so operators can respond quickly.

Pattern	Purpose
Health Endpoint Monitoring	Expose operational health for monitoring tools
Ambassador	Offload cross-cutting concerns like logging and monitoring
Sidecar	Deploy monitoring agents alongside application containers
External Configuration Store	Centralize configuration management

Azure services

Azure Monitor — metrics, logs, and alerts across all Azure resources
Application Insights — application performance monitoring and distributed tracing
Azure Log Analytics — centralized log querying with KQL
Azure Resource Manager (ARM) / Bicep — infrastructure as code
Azure DevOps / GitHub Actions — CI/CD pipelines

7. Use managed services

Prefer platform as a service (PaaS) over infrastructure as a service (IaaS) wherever possible to reduce operational overhead.

Recommendations

Default to PaaS for compute, databases, messaging, and storage — let Azure handle OS patching, scaling, and high availability.
Use IaaS only when you need fine-grained control over the operating system, runtime, or network configuration that PaaS cannot provide.
Leverage built-in scaling and redundancy features of managed services instead of building and maintaining them yourself.

Pattern	Purpose
Backends for Frontends	Use managed API gateways per client type
Gateway Aggregation	Aggregate calls through a managed gateway
Static Content Hosting	Use managed storage for static assets

Azure services

IaaS	PaaS Alternative
VMs with IIS/Nginx	Azure App Service
VMs with SQL Server	Azure SQL Database
VMs with RabbitMQ	Azure Service Bus
VMs with Kubernetes	Azure Kubernetes Service (AKS)
VMs with custom functions	Azure Functions
VMs with Redis	Azure Cache for Redis
VMs with Elasticsearch	Azure AI Search

8. Use an identity service

Use a centralized identity platform instead of building or managing your own authentication and authorization system.

Recommendations

Use Microsoft Entra ID (formerly Azure AD) as the single identity provider for users, applications, and service-to-service authentication.
Never store credentials in application code or configuration — use managed identities, certificate-based auth, or federated credentials.
Implement federation protocols (SAML, OIDC, OAuth 2.0) to integrate with external identity providers and enable single sign-on.
Adopt modern security features — passwordless authentication (FIDO2, Windows Hello), conditional access policies, multi-factor authentication (MFA), and single sign-on (SSO).
Use managed identities for Azure resources to eliminate credential management for service-to-service communication entirely.

Pattern	Purpose
Federated Identity	Delegate authentication to an external identity provider
Gatekeeper	Protect backends by validating identity at the edge
Valet Key	Grant scoped, time-limited access to resources

Azure services

Microsoft Entra ID — cloud identity and access management
Azure Managed Identities — credential-free service-to-service auth
Azure Key Vault — secrets, certificates, and key management
Microsoft Entra External ID — customer and partner identity (B2C/B2B)

9. Design for evolution

Design the architecture so it can evolve over time as requirements, technologies, and team understanding change.

Recommendations

Enforce loose coupling and high cohesion — services should expose well-defined interfaces and encapsulate their internal implementation details.
Encapsulate domain knowledge within service boundaries so changes to business logic don't ripple across the system.
Use asynchronous messaging between services to reduce temporal coupling — services don't need to be available at the same time.
Version APIs from day one so clients can migrate at their own pace and you can evolve without breaking existing consumers.
Deploy services independently with their own release cadence — avoid coordinated "big bang" deployments.

Pattern	Purpose
Anti-Corruption Layer	Isolate new services from legacy systems
Strangler Fig	Incrementally migrate a monolith to microservices
Backends for Frontends	Evolve APIs independently per client type
Gateway Routing	Route requests to different service versions

Azure services

Azure API Management — API versioning, routing, and lifecycle management
Azure Kubernetes Service (AKS) — independent service deployments with rolling updates
Azure Service Bus — asynchronous inter-service messaging
Azure Container Apps — revision-based deployments with traffic splitting

10. Build for the needs of business

Every design decision must be justified by a business requirement. Align technical choices with business goals, constraints, and growth plans.

Recommendations

Define RTO, RPO, and MTO (Recovery Time Objective, Recovery Point Objective, Maximum Tolerable Outage) for each workload based on business impact analysis.
Document SLAs and SLOs — understand the composite SLA of your architecture and set internal SLOs that provide an error budget for engineering work.
Model the system around the business domain using domain-driven design to ensure the architecture reflects how the business operates.
Define functional and nonfunctional requirements explicitly — capture performance targets, compliance needs, data residency constraints, and user experience expectations.
Plan for growth — design capacity models that account for business projections, seasonal peaks, and market expansion.

Pattern	Purpose
Priority Queue	Process business-critical work first
Throttling	Protect SLOs under heavy load
Deployment Stamps	Scale to new markets and regions
Bulkhead	Isolate critical workloads from non-critical ones

Azure services

Azure Advisor — cost, performance, reliability, and security recommendations
Azure Cost Management — budget tracking and cost optimization
Azure Service Health — SLA tracking and incident awareness
Azure Well-Architected Framework Review — assess architecture against best practices
Azure Monitor SLO/SLI dashboards — measure and track service level objectives

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

2026-11-08

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download cloud-solution-architect.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Microsoft

Cloud Solution Architect

Overview

Ten Design Principles for Azure Applications

Architecture Styles

Selection Criteria

Cloud Design Patterns

Messaging & Communication

Reliability & Resilience

Data Management

Design & Structure

Security & Access

Deployment & Scaling

Technology Choices

Decision Framework

Best Practices

Performance Antipatterns

Mission-Critical Design

Well-Architected Framework (WAF) Pillars

WAF Tradeoff Matrix

Architecture Review Workflow

Step 1: Identify Requirements

Step 2: Select Architecture Style

Step 3: Choose Technology Stack

Step 4: Apply Design Patterns

Step 5: Address Cross-Cutting Concerns

Step 6: Validate Against WAF Pillars

Step 7: Document Decisions

References

Source

Files

references/design-principles.md

Azure Design Principles

1. Design for self-healing

Recommendations

Related design patterns

Azure services

2. Make all things redundant

Recommendations

Related design patterns

Azure services

3. Minimize coordination

Recommendations

Related design patterns

Azure services

4. Design to scale out

Recommendations

Related design patterns

Azure services

5. Partition around limits

Recommendations

Related design patterns

Azure services

6. Design for operations

Recommendations

Related design patterns

Azure services

7. Use managed services

Recommendations

Related design patterns

Azure services

8. Use an identity service

Recommendations

Related design patterns

Azure services

9. Design for evolution

Recommendations

Related design patterns

Azure services

10. Build for the needs of business

Recommendations

Related design patterns

Azure services