用途
Cloud Architect 提供跨主流云厂商的架构设计专业能力，目标是设计可扩展、安全且具成本效益的云架构。其处理范围包括基础设施设计、云迁移规划、多云策略与云成本优化。
何时使用
适合在以下场景调用：设计云原生架构；规划云迁移策略；实现多云或混合云方案；优化云成本与资源利用率；选择云服务与区域；设计灾难恢复方案；设置云治理与安全。
不适用场景
资料明确列出不应调用的情况：编写 Terraform/IaC 代码（改用 terraform-engineer）；管理 Kubernetes 集群（改用 kubernetes-specialist）；实现 CI/CD 流水线（改用 devops-engineer）；Azure 专属基础设施（改用 azure-infra-engineer）。
决策框架
云厂商选择：采用 Microsoft 技术栈的企业 → Azure；初创/原生 Web 业务 → AWS 或 GCP；ML/AI 工作负载 → GCP 或 AWS；以数据分析为重点 → GCP BigQuery 或 AWS Redshift；担心厂商锁定 → 使用 K8s 的多云方案；受监管行业 → 私有云或混合云。 服务类型选择：无状态工作负载 → Serverless（Lambda、Functions）；容器工作负载 → 托管 K8s（EKS、AKS、GKE）；遗留应用 → 虚拟机（EC2、Compute Engine）；事件驱动 → 事件服务（EventBridge、Pub/Sub）。
核心工作流
- 云架构设计：收集需求与约束；定义可用性与灾难恢复要求；按层级选择合适服务；设计网络拓扑与安全；规划可扩展性与弹性；记录架构决策；估算成本并优化。
- 云迁移规划：评估现有基础设施（6 Rs）；确定迁移工作负载优先级；设计着陆区架构；规划数据迁移策略；定义迁移批次；制定回滚流程；规划切换与验证。
- 成本优化：分析当前支出模式；识别闲置或未充分利用的资源；实施合理规格建议；应用预留/竞价实例；建立成本监控与告警；实施自动扩缩容策略。
最佳实践
以多可用区部署实现故障设计；尽可能使用托管服务而非自管理；实施最小权限访问控制；为所有资源打标签以便成本分摊；用 IaC 自动化基础设施；从第一天起就按 10 倍规模做规划。
反模式
- 仅做直接迁移（lift-and-shift）：错过云的优势 → 针对云原生进行重构。
- 单可用区部署：无容错能力 → 多可用区或多区域。
- 缺乏成本控制：预算超支 → 设置预算与告警。
- 配置硬编码：基础设施脆弱 → 使用参数存储与 IaC。
- 过度设计：不必要的复杂性 → 从简单开始，逐步演进。
限制
资料未提供具体收费、价格、平台支持矩阵、实际效果数据或详细实施步骤，以上内容暂未提供。