‹ 首页

cloud-architect

@jeffallan · 收录于 1 周前 · 上游提交 1 个月前

Designs cloud architectures, creates migration plans, generates cost optimization recommendations, and produces disaster recovery strategies across AWS, Azure, and GCP. Use when designing cloud architectures, planning migrations, or optimizing multi-cloud deployments. Invoke for Well-Architected Framework, cost optimization, disaster recovery, landing zones, security architecture, serverless design.

适合你,如果你需要设计或优化多云架构

/ 下载安装
cloud-architect.skill双击,或拖进 Claude 桌面版 / Cowork,即完成安装↓ .skill↓ .zip
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code~/.claude/skills/(项目级 .claude/skills/)
Codex CLI~/.codex/skills/
Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add jeffallan/claude-skills/cloud-architect
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- jeffallan/claude-skills/cloud-architect
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify jeffallan/claude-skills/cloud-architect
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
10501GitHub stars
~1.3K最小装载
~13.7K含声明引用
~13.7K文本包总量
镜像托管

怎么用

商店整理自技能原文 · 版本 e8be415 · 表述以原文为准
它做什么

装上后,Claude 会帮你设计云架构、制定迁移计划、优化成本,并生成灾难恢复策略。它支持 AWS、Azure 和 GCP 三大云平台。

什么时候触发

当你需要设计云架构、规划迁移或优化多云部署时触发。也适用于 Well-Architected 框架、成本优化、灾难恢复等场景。

装好后可以这样说
Claude 会生成架构图、服务选择、安全方案和成本估算。
Claude 会输出迁移阶段、验证步骤和回滚方案。
Claude 会运行成本分析命令并给出优化建议。
技能原文 SKILL.md作者撰写 · MIT · e8be415

Cloud Architect

Core Workflow
  1. Discovery — Assess current state, requirements, constraints, compliance needs
  2. Design — Select services, design topology, plan data architecture
  3. Security — Implement zero-trust, identity federation, encryption
  4. Cost Model — Right-size resources, reserved capacity, auto-scaling
  5. Migration — Apply 6Rs framework, define waves, validate connectivity before cutover
  6. Operate — Set up monitoring, automation, continuous optimization
Workflow Validation Checkpoints

After Design: Confirm every component has a redundancy strategy and no single points of failure exist in the topology.

Before Migration cutover: Validate VPC peering or connectivity is fully established:

# AWS: confirm peering connection is Active before proceeding
aws ec2 describe-vpc-peering-connections \
  --filters "Name=status-code,Values=active"

# Azure: confirm VNet peering state
az network vnet peering list \
  --resource-group myRG --vnet-name myVNet \
  --query "[].{Name:name,State:peeringState}"

After Migration: Verify application health and routing:

# AWS: check target group health in ALB
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:...

After DR test: Confirm RTO/RPO targets were met; document actual recovery times.

Reference Guide

Load detailed guidance based on context:

| Topic | Reference | Load When | |-------|-----------|-----------| | AWS Services | references/aws.md | EC2, S3, Lambda, RDS, Well-Architected Framework | | Azure Services | references/azure.md | VMs, Storage, Functions, SQL, Cloud Adoption Framework | | GCP Services | references/gcp.md | Compute Engine, Cloud Storage, Cloud Functions, BigQuery | | Multi-Cloud | references/multi-cloud.md | Abstraction layers, portability, vendor lock-in mitigation | | Cost Optimization | references/cost.md | Reserved instances, spot, right-sizing, FinOps practices |

Constraints
MUST DO
  • Design for high availability (99.9%+)
  • Implement security by design (zero-trust)
  • Use infrastructure as code (Terraform, CloudFormation)
  • Enable cost allocation tags and monitoring
  • Plan disaster recovery with defined RTO/RPO
  • Implement multi-region for critical workloads
  • Use managed services when possible
  • Document architectural decisions
MUST NOT DO
  • Store credentials in code or public repos
  • Skip encryption (at rest and in transit)
  • Create single points of failure
  • Ignore cost optimization opportunities
  • Deploy without proper monitoring
  • Use overly complex architectures
  • Ignore compliance requirements
  • Skip disaster recovery testing
Common Patterns with Examples
Least-Privilege IAM (Zero-Trust)

Rather than broad policies, scope permissions to specific resources and actions:

# AWS: create a scoped role for an application
aws iam create-role \
  --role-name AppRole \
  --assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \
  --role-name AppRole \
  --policy-name AppInlinePolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }]
  }'
# Terraform equivalent
resource "aws_iam_role" "app_role" {
  name               = "AppRole"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

resource "aws_iam_role_policy" "app_policy" {
  role = aws_iam_role.app_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "${aws_s3_bucket.app.arn}/*"
    }]
  })
}
VPC with Public/Private Subnets (Terraform)
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = { Name = "main", CostCenter = var.cost_center }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet("10.0.0.0/16", 8, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet("10.0.0.0/16", 8, count.index + 10)
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
}
Auto-Scaling Group (Terraform)
resource "aws_autoscaling_group" "app" {
  desired_capacity    = 2
  min_size            = 1
  max_size            = 10
  vpc_zone_identifier = aws_subnet.private[*].id

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }

  tag {
    key                 = "CostCenter"
    value               = var.cost_center
    propagate_at_launch = true
  }
}

resource "aws_autoscaling_policy" "cpu_target" {
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0
  }
}
Cost Analysis CLI
# AWS: identify top cost drivers for the last 30 days
aws ce get-cost-and-usage \
  --time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
  --output table

# Azure: review spend by resource group
az consumption usage list \
  --start-date $(date -d '30 days ago' +%Y-%m-%d) \
  --end-date $(date +%Y-%m-%d) \
  --query "[].{ResourceGroup:resourceGroup,Cost:pretaxCost,Currency:currency}" \
  --output table
Output Templates

When designing cloud architecture, provide:

  1. Architecture diagram with services and data flow
  2. Service selection rationale (compute, storage, database, networking)
  3. Security architecture (IAM, network segmentation, encryption)
  4. Cost estimation and optimization strategy
  5. Deployment approach and rollback plan

Documentation

按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。