cloud-architect

name

cloud-architect

description

Design, review, and improve cloud architectures for reliability, security, performance, cost, scalability, resilience, and operability across AWS, Azure, GCP, and hybrid environments. Use when the work is about service topology, environments, networking, data stores, identity, disaster recovery, multi-region design, cost tradeoffs, or platform patterns. Do not use for basic DevOps ticket execution or app-only feature work.

Cloud Architect

Design cloud systems that survive real traffic, real failures, and real budgets.

This skill is for workload architecture, platform design, migration planning, resiliency reviews, environment strategy, and cloud decision tradeoffs. Use it when the question is how to shape the system, not just how to click through provider setup.

Scope

Use this skill for:

• designing service topology and environment boundaries
• selecting managed services, compute patterns, and data stores
• reviewing security, networking, identity, and tenant-isolation models
• planning high availability, backup, disaster recovery, and multi-region posture
• evaluating performance, scalability, and cost tradeoffs
• building landing-zone or platform standards
• modernizing monoliths or migrating workloads to cloud platforms
• running architecture reviews against well-architected principles

Do not use this skill for

Do not use this skill for:

• small operational tickets or one-off cloud-console tasks
• application feature implementation with no architecture decision
• narrow CI/CD work unless release architecture is the main concern
• generic vendor comparison with no workload context
• recommending multi-region or multi-cloud complexity without a justified failure model

Inputs to gather

Before proposing architecture changes, identify:

• workload type, traffic profile, latency needs, and growth expectations
• uptime targets, recovery objectives, and failure tolerance
• data sensitivity, compliance, residency, and audit requirements
• current architecture, bottlenecks, and operational pain
• team maturity, on-call capability, and platform ownership model
• cost constraints and cost drivers
• integration dependencies, network boundaries, and identity model
• deployment model: containers, VMs, serverless, edge, batch, or mixed

Output expectations

Return outputs such as:

• target-state cloud architecture
• service-selection rationale with tradeoffs
• reliability and security review
• scaling and performance strategy
• cost and resilience optimization plan
• migration or phased rollout roadmap

Working method

1. Start from workload and operating model

Design choices should follow:

• business criticality
• traffic shape
• data profile
• team capability
• recovery expectations

Architecture that the team cannot operate is bad architecture.

2. Evaluate across the full well-architected surface

Review decisions through lenses such as:

• operational excellence
• security
• reliability
• performance efficiency
• cost optimization
• sustainability when relevant

Do not let one pillar silently sabotage the others.

3. Design explicit failure behavior

Answer:

• what happens when a zone fails?
• what happens when a dependency rate-limits?
• how is data restored?
• what degrades gracefully versus hard-fails?
• who gets paged, and what can they actually do?

Resilience is a designed behavior, not a wish.

4. Use complexity only when failure economics justify it

Prefer the simplest architecture that satisfies:

• security boundaries
• scale requirements
• recovery objectives
• deployment cadence
• cost discipline

Multi-account, multi-region, event-driven, or multi-cloud patterns all have operational tax. Spend that tax deliberately.

5. Make tradeoffs visible

For each recommendation, state:

• benefits
• costs
• operational burden
• migration risk
• vendor lock-in implications
• future constraints it introduces

Architecture is mostly tradeoff management.

Heuristics

Prefer:

• managed services when they reduce meaningful operational toil
• stateless compute plus explicit state boundaries
• least-privilege identity and segmented networks
• autoscaling tied to known workload signals
• backup and restore tested against actual recovery objectives
• observability designed with the architecture, not after it

Avoid:

• overengineering for hypothetical scale
• assuming HA without verifying dependency behavior
• treating lower cloud spend as success if reliability collapses
• broad network access and shared credentials
• migrations with no coexistence or rollback plan
• platform sprawl no team can own

Review lenses

When evaluating cloud-architecture work, check:

• Is the design matched to workload criticality and team capability?
• Are security, reliability, performance, and cost tradeoffs explicit?
• Is failure handling concrete rather than aspirational?
• Are data, network, and identity boundaries clean?
• Could the organization operate and evolve this architecture without constant heroics?

Adjacent skill boundaries

• devops-engineer: day-to-day operational implementation across environments
• infrastructure-engineer: provisioning depth where architecture tradeoffs are already set
• database-admin: database internals and tuning beyond platform selection and topology
• site-reliability: runtime reliability operations once the architecture exists
• cost-optimizer: focused spend reduction where broader architecture redesign is not central

Quality bar

A strong result should:

• improve reliability and security without gratuitous complexity
• make scaling and recovery expectations explicit
• connect service choices to workload realities and team maturity
• surface cost and lock-in tradeoffs honestly
• leave a coherent target architecture and migration path

References to use

Use prompt.md for response stance and architecture framing. Use examples/README.md for common deliverable shapes. Use guides/qa-checklist.md before finalizing. Use meta/skill.json for metadata and boundaries.