cloud-architect

Name: cloud-architect
Author: Jeffallan

11kstars971forks

How to install cloud-architect?

jeffallan/claude-skills/cloud-architect

$npx -y skills add Jeffallan/claude-skills --skill cloud-architect

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Cloud Architect
2
3	## Core Workflow
4
5	1. Discovery — Assess current state, requirements, constraints, compliance needs
6	2. Design — Select services, design topology, plan data architecture
7	3. Security — Implement zero-trust, identity federation, encryption
8	4. Cost Model — Right-size resources, reserved capacity, auto-scaling
9	5. Migration — Apply 6Rs framework, define waves, validate connectivity before cutover
10	6. Operate — Set up monitoring, automation, continuous optimization
11
12	### Workflow Validation Checkpoints
13
14	After Design: Confirm every component has a redundancy strategy and no single points of failure exist in the topology.
15
16	Before Migration cutover: Validate VPC peering or connectivity is fully established:
17	```bash
18	# AWS: confirm peering connection is Active before proceeding
19	aws ec2 describe-vpc-peering-connections \
20	--filters "Name=status-code,Values=active"
21
22	# Azure: confirm VNet peering state
23	az network vnet peering list \
24	--resource-group myRG --vnet-name myVNet \
25	--query "[].{Name:name,State:peeringState}"
26	```
27
28	After Migration: Verify application health and routing:
29	```bash
30	# AWS: check target group health in ALB
31	aws elbv2 describe-target-health \
32	--target-group-arn arn:aws:elasticloadbalancing:...
33	```
34
35	After DR test: Confirm RTO/RPO targets were met; document actual recovery times.
36
37	## Reference Guide
38
39	Load detailed guidance based on context:
40
41	\| Topic \| Reference \| Load When \|
42	\|-------\|-----------\|-----------\|
43	\| AWS Services \| `references/aws.md` \| EC2, S3, Lambda, RDS, Well-Architected Framework \|
44	\| Azure Services \| `references/azure.md` \| VMs, Storage, Functions, SQL, Cloud Adoption Framework \|
45	\| GCP Services \| `references/gcp.md` \| Compute Engine, Cloud Storage, Cloud Functions, BigQuery \|
46	\| Multi-Cloud \| `references/multi-cloud.md` \| Abstraction layers, portability, vendor lock-in mitigation \|
47	\| Cost Optimization \| `references/cost.md` \| Reserved instances, spot, right-sizing, FinOps practices \|
48
49	## Constraints
50
51	### MUST DO
52	- Design for high availability (99.9%+)
53	- Implement security by design (zero-trust)
54	- Use infrastructure as code (Terraform, CloudFormation)
55	- Enable cost allocation tags and monitoring
56	- Plan disaster recovery with defined RTO/RPO
57	- Implement multi-region for critical workloads
58	- Use managed services when possible
59	- Document architectural decisions
60
61	### MUST NOT DO
62	- Store credentials in code or public repos
63	- Skip encryption (at rest and in transit)
64	- Create single points of failure
65	- Ignore cost optimization opportunities
66	- Deploy without proper monitoring
67	- Use overly complex architectures
68	- Ignore compliance requirements
69	- Skip disaster recovery testing
70
71	## Common Patterns with Examples
72
73	### Least-Privilege IAM (Zero-Trust)
74
75	Rather than broad policies, scope permissions to specific resources and actions:
76
77	```bash
78	# AWS: create a scoped role for an application
79	aws iam create-role \
80	--role-name AppRole \
81	--assume-role-policy-document file://trust-policy.json
82
83	aws iam put-role-policy \
84	--role-name AppRole \
85	--policy-name AppInlinePolicy \
86	--policy-document '{
87	"Version": "2012-10-17",
88	"Statement": [{
89	"Effect": "Allow",
90	"Action": ["s3:GetObject", "s3:PutObject"],
91	"Resource": "arn:aws:s3:::my-app-bucket/*"
92	}]
93	}'
94	```
95
96	```hcl
97	# Terraform equivalent
98	resource "aws_iam_role" "app_role" {
99	name = "AppRole"
100	assume_role_policy = data.aws_iam_policy_document.trust.json
101	}
102
103	resource "aws_iam_role_policy" "app_policy" {
104	role = aws_iam_role.app_role.id
105	policy = jsonencode({
106	Version = "2012-10-17"
107	Statement = [{
108	Effect = "Allow"
109	Action = ["s3:GetObject", "s3:PutObject"]
110	Resource = "${aws_s3_bucket.app.arn}/*"
111	}]
112	})
113	}
114	```
115
116	### VPC with Public/Private Subnets (Terraform)
117
118	```hcl
119	resource "aws_vpc" "main" {
120	cidr_block = "10.0.0.0/16"
121	enable_dns_hostnames = true
122	tags = { Name = "main", CostCenter = var.cost_center }
123	}
124
125	resource "aws_subnet" "private" {
126	count =

People who liked this also viewed

6 picks

Type

cloud-architect

11kstars971forks

View on GitHub

How to install cloud-architect?

jeffallan/claude-skills/cloud-architect

$npx -y skills add Jeffallan/claude-skills --skill cloud-architect

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Cloud Architect
2
3	## Core Workflow
4
5	1. Discovery — Assess current state, requirements, constraints, compliance needs
6	2. Design — Select services, design topology, plan data architecture
7	3. Security — Implement zero-trust, identity federation, encryption
8	4. Cost Model — Right-size resources, reserved capacity, auto-scaling
9	5. Migration — Apply 6Rs framework, define waves, validate connectivity before cutover
10	6. Operate — Set up monitoring, automation, continuous optimization
11
12	### Workflow Validation Checkpoints
13
14	After Design: Confirm every component has a redundancy strategy and no single points of failure exist in the topology.
15
16	Before Migration cutover: Validate VPC peering or connectivity is fully established:
17	```bash
18	# AWS: confirm peering connection is Active before proceeding
19	aws ec2 describe-vpc-peering-connections \
20	--filters "Name=status-code,Values=active"
21
22	# Azure: confirm VNet peering state
23	az network vnet peering list \
24	--resource-group myRG --vnet-name myVNet \
25	--query "[].{Name:name,State:peeringState}"
26	```
27
28	After Migration: Verify application health and routing:
29	```bash
30	# AWS: check target group health in ALB
31	aws elbv2 describe-target-health \
32	--target-group-arn arn:aws:elasticloadbalancing:...
33	```
34
35	After DR test: Confirm RTO/RPO targets were met; document actual recovery times.
36
37	## Reference Guide
38
39	Load detailed guidance based on context:
40
41	\| Topic \| Reference \| Load When \|
42	\|-------\|-----------\|-----------\|
43	\| AWS Services \| `references/aws.md` \| EC2, S3, Lambda, RDS, Well-Architected Framework \|
44	\| Azure Services \| `references/azure.md` \| VMs, Storage, Functions, SQL, Cloud Adoption Framework \|
45	\| GCP Services \| `references/gcp.md` \| Compute Engine, Cloud Storage, Cloud Functions, BigQuery \|
46	\| Multi-Cloud \| `references/multi-cloud.md` \| Abstraction layers, portability, vendor lock-in mitigation \|
47	\| Cost Optimization \| `references/cost.md` \| Reserved instances, spot, right-sizing, FinOps practices \|
48
49	## Constraints
50
51	### MUST DO
52	- Design for high availability (99.9%+)
53	- Implement security by design (zero-trust)
54	- Use infrastructure as code (Terraform, CloudFormation)
55	- Enable cost allocation tags and monitoring
56	- Plan disaster recovery with defined RTO/RPO
57	- Implement multi-region for critical workloads
58	- Use managed services when possible
59	- Document architectural decisions
60
61	### MUST NOT DO
62	- Store credentials in code or public repos
63	- Skip encryption (at rest and in transit)
64	- Create single points of failure
65	- Ignore cost optimization opportunities
66	- Deploy without proper monitoring
67	- Use overly complex architectures
68	- Ignore compliance requirements
69	- Skip disaster recovery testing
70
71	## Common Patterns with Examples
72
73	### Least-Privilege IAM (Zero-Trust)
74
75	Rather than broad policies, scope permissions to specific resources and actions:
76
77	```bash
78	# AWS: create a scoped role for an application
79	aws iam create-role \
80	--role-name AppRole \
81	--assume-role-policy-document file://trust-policy.json
82
83	aws iam put-role-policy \
84	--role-name AppRole \
85	--policy-name AppInlinePolicy \
86	--policy-document '{
87	"Version": "2012-10-17",
88	"Statement": [{
89	"Effect": "Allow",
90	"Action": ["s3:GetObject", "s3:PutObject"],
91	"Resource": "arn:aws:s3:::my-app-bucket/*"
92	}]
93	}'
94	```
95
96	```hcl
97	# Terraform equivalent
98	resource "aws_iam_role" "app_role" {
99	name = "AppRole"
100	assume_role_policy = data.aws_iam_policy_document.trust.json
101	}
102
103	resource "aws_iam_role_policy" "app_policy" {
104	role = aws_iam_role.app_role.id
105	policy = jsonencode({
106	Version = "2012-10-17"
107	Statement = [{
108	Effect = "Allow"
109	Action = ["s3:GetObject", "s3:PutObject"]
110	Resource = "${aws_s3_bucket.app.arn}/*"
111	}]
112	})
113	}
114	```
115
116	### VPC with Public/Private Subnets (Terraform)
117
118	```hcl
119	resource "aws_vpc" "main" {
120	cidr_block = "10.0.0.0/16"
121	enable_dns_hostnames = true
122	tags = { Name = "main", CostCenter = var.cost_center }
123	}
124
125	resource "aws_subnet" "private" {
126	count =

People who liked this also viewed

6 picks

Type