cloud-engineering
Skill4 starsChanged 12 months agoMITView on GitHub
Cloud engineering guide covering AWS, Azure, GCP, and Oracle Cloud (OCI) services, multi-cloud strategies, serverless architectures, cloud-native patterns, cost optimization, cloud networking, security, migration strategies, and Well-Architected frameworks. Use when designing cloud infrastructure, implementing cloud services, optimizing cloud costs, or planning cloud migrations. (project)
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 20 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈20
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 49
When starting a cloud engineering task:
- Distinctive: line 119
Document and share knowledge
- Distinctive: line 536
Use multiple availability zones
- Distinctive: line 538
Test failure scenarios regularly
- Distinctive: line 543
Use managed identity services
- Distinctive: line 548
Use auto-scaling to match demand
- Distinctive: line 555
Prefer managed services over self-managed
- Distinctive: line 561
Start small, scale as needed
- Distinctive: line 563
Use burstable instances for variable workloads
- Distinctive: line 564
Consider serverless for intermittent loads
- Distinctive: line 568
Consider data residency requirements
- Distinctive: line 569
Check service availability by region
- Distinctive: line 575
Use containers and Kubernetes
- Distinctive: line 611
Create Lambda functions with proper IAM roles
- Distinctive: line 616
Test with load testing tools
- Distinctive: line 617
Document API and operational runbooks
- Distinctive: line 628
Document disaster recovery procedures
- Distinctive: line 638
Use spot instances for fault-tolerant workloads
- Distinctive: line 659
Use cloud-specific IaC (CloudFormation, ARM templates, Terraform)
- Distinctive: line 668
Test in development environment first
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🎯 SKILL ACTIVATED: cloud-engineering ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Cloud Engineering
Comprehensive guide for designing, building, and managing cloud infrastructure across AWS, Azure, GCP, and Oracle Cloud Infrastructure (OCI). This skill provides production-tested patterns for cloud-native architectures, multi-cloud strategies, serverless computing, and cloud optimization.
When to Use This Skill
Automatically activates when working on:
- AWS, Azure, GCP, or Oracle Cloud (OCI) service selection and implementation
- Cloud architecture design and cloud-native patterns
- Multi-cloud and hybrid cloud strategies
- Serverless application development (Lambda, Cloud Functions, Azure Functions, OCI Functions)
- Cloud networking (VPC, VNet, Cloud VPC, OCI VCN)
- Cloud cost optimization and FinOps practices
- Cloud security and IAM configuration
- Cloud migration planning and execution
- Well-Architected Framework implementation
Overview
Purpose: Enable teams to build robust, scalable cloud infrastructure leveraging the best services from AWS, Azure, and GCP while maintaining portability, cost efficiency, and operational excellence.
Scope:
- Cloud service selection and architecture (AWS, Azure, GCP, OCI)
- Multi-cloud and hybrid cloud strategies
- Serverless and event-driven architectures
- Cloud cost optimization and FinOps
- Cloud networking (VPC, VNet, VCN, peering, transit gateway, DNS)
- Cloud security and compliance (IAM, encryption, audit)
- Migration strategies and modernization
- Well-Architected frameworks and best practices
This skill is for:
- Cloud engineers designing cloud-native solutions
- Architects choosing between cloud services
- Teams implementing multi-cloud strategies
- Organizations migrating to cloud
- Engineers optimizing cloud costs
Quick Start Checklist
When starting a cloud engineering task:
- Define requirements (scale, performance, compliance, budget)
- Choose cloud provider(s) based on needs
- Design for Well-Architected principles
- Plan networking topology (VPC, subnets, routing)
- Implement identity and access management
- Enable encryption at rest and in transit
- Set up cost tracking and budgets
- Implement monitoring and logging
- Design for high availability and disaster recovery
- Document architecture and operational runbooks
Core Concepts
1. Cloud Service Models
IaaS (Infrastructure as a Service):
Control: ████████░░ High control, high responsibility
Examples: EC2, Azure VMs, Compute Engine
Use Case: Lift-and-shift, custom configurationsPaaS (Platform as a Service):
Control: █████░░░░░ Balanced control and management
Examples: Elastic Beanstalk, App Service, App Engine
Use Case: Application deployment, reduced opsFaaS (Function as a Service):
Control: ██░░░░░░░░ Low control, minimal management
Examples: Lambda, Azure Functions, Cloud Functions
Use Case: Event-driven, serverless, pay-per-useManaged Services:
Control: ███░░░░░░░ Vendor-managed operations
Examples: RDS, Cosmos DB, Cloud SQL
Use Case: Databases, analytics, managed ops2. Cloud Provider Comparison
┌─────────────────┬──────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ Service │ AWS │ Azure │ GCP │ OCI │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ Compute │ EC2 │ Virtual Machines │ Compute Engine │ Compute Instance │
│ Containers │ ECS, EKS │ ACI, AKS │ GKE, Cloud Run │ OKE, Instances │
│ Serverless │ Lambda │ Functions │ Cloud Functions │ Functions │
│ Storage │ S3 │ Blob Storage │ Cloud Storage │ Object Storage │
│ Database │ RDS, DynamoDB │ SQL, Cosmos DB │ Cloud SQL, Spanner│ Autonomous DB │
│ Networking │ VPC │ Virtual Network │ VPC │ VCN │
│ DNS │ Route 53 │ DNS │ Cloud DNS │ DNS │
│ CDN │ CloudFront │ CDN │ Cloud CDN │ CDN │
│ IAM │ IAM │ Active Directory │ IAM │ IAM │
│ Monitoring │ CloudWatch │ Monitor │ Cloud Monitoring │ Monitoring │
└─────────────────┴──────────────────┴──────────────────┴──────────────────┴──────────────────┘3. Well-Architected Principles
Five Pillars (AWS Framework):
- Operational Excellence:
- Automate operations
- Document and share knowledge
- Make frequent, small changes
- Anticipate failure and learn
- Security:
- Implement strong identity foundation
- Enable traceability
- Apply security at all layers
- Protect data in transit and at rest
- Reliability:
- Test recovery procedures
- Automatically recover from failure
- Scale horizontally
- Stop guessing capacity
- Performance Efficiency:
- Use serverless architectures
- Experiment and innovate
- Go global in minutes
- Consider mechanical sympathy
- Cost Optimization:
- Adopt consumption model
- Measure overall efficiency
- Eliminate undifferentiated work
- Analyze and attribute expenditure
4. Multi-Cloud Architecture
┌────────────────────────────────────────────────────┐
│ Application Layer (Multi-Cloud) │
│ (Containers, Kubernetes, Serverless) │
└────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────┐
│ Abstraction Layer (Terraform, Pulumi) │
│ (Service Mesh, API Gateway, CDN) │
└────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌─────▼────┐ ┌─────▼────┐ ┌─────▼────┐
│ AWS │ │ Azure │ │ GCP │
│ Services │ │ Services │ │ Services │
└──────────┘ └──────────┘ └──────────┘5. Serverless Architecture
Event-Driven Pattern:
Event Source → Event Router → Lambda Function → Destination
│ │ │ │
S3/API EventBridge Process Database
Upload Rules Transform SNS/SQSBenefits:
- No server management
- Automatic scaling
- Pay per execution
- Built-in high availability
Challenges:
- Cold starts
- Vendor lock-in
- Debugging complexity
- Execution limits
Common Patterns
Pattern 1: Multi-Region Architecture
# High availability across regions
Architecture:
Primary Region (us-east-1):
- Application tier (Auto Scaling)
- Database (RDS Multi-AZ)
- Cache (ElastiCache cluster)
- Load balancer (ALB)
Secondary Region (us-west-2):
- Read replicas (RDS)
- Standby infrastructure
- S3 cross-region replication
Global:
- Route 53 (DNS failover)
- CloudFront (CDN)
- DynamoDB Global TablesImplementation (Terraform):
# Multi-region deployment
provider "aws" {
alias = "primary"
region = "us-east-1"
}
provider "aws" {
alias = "secondary"
region = "us-west-2"
}
# Primary region resources
module "primary_region" {
source = "./modules/region"
providers = {
aws = aws.primary
}
environment = "production"
region_type = "primary"
enable_rds = true
enable_cache = true
multi_az = true
}
# Secondary region (DR)
module "secondary_region" {
source = "./modules/region"
providers = {
aws = aws.secondary
}
environment = "production"
region_type = "secondary"
enable_rds = false # Read replica
enable_cache = true
multi_az = false
}
# Global services
resource "aws_route53_health_check" "primary" {
fqdn = module.primary_region.load_balancer_dns
port = 443
type = "HTTPS"
resource_path = "/health"
failure_threshold = 3
request_interval = 30
}
resource "aws_route53_record" "failover_primary" {
zone_id = aws_route53_zone.main.zone_id
name = "api.example.com"
type = "A"
failover_routing_policy {
type = "PRIMARY"
}
set_identifier = "primary"
health_check_id = aws_route53_health_check.primary.id
alias {
name = module.primary_region.load_balancer_dns
zone_id = module.primary_region.load_balancer_zone_id
evaluate_target_health = true
}
}Pattern 2: Serverless API Architecture
# API Gateway + Lambda + DynamoDB
apiVersion: v1
kind: ServerlessAPI
spec:
components:
apiGateway:
type: REST
authentication: Cognito
throttling:
rateLimit: 10000
burstLimit: 5000
functions:
- name: getUser
runtime: nodejs18.x
memory: 256
timeout: 10
triggers:
- http:
path: /users/{id}
method: GET
- name: createUser
runtime: nodejs18.x
memory: 512
timeout: 30
triggers:
- http:
path: /users
method: POST
database:
type: DynamoDB
tables:
- name: Users
partitionKey: userId
sortKey: timestamp
globalSecondaryIndexes:
- name: EmailIndex
partitionKey: emailImplementation (AWS SAM):
# template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Globals:
Function:
Runtime: nodejs18.x
Timeout: 30
MemorySize: 256
Environment:
Variables:
TABLE_NAME: !Ref UsersTable
REGION: !Ref AWS::Region
Resources:
ApiGateway:
Type: AWS::Serverless::Api
Properties:
StageName: prod
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
Cors:
AllowMethods: "'GET,POST,PUT,DELETE'"
AllowHeaders: "'Content-Type,Authorization'"
AllowOrigin: "'*'"
MethodSettings:
- ResourcePath: '/*'
HttpMethod: '*'
ThrottlingRateLimit: 10000
ThrottlingBurstLimit: 5000
GetUserFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/getUser/
Handler: index.handler
Events:
GetUser:
Type: Api
Properties:
RestApiId: !Ref ApiGateway
Path: /users/{id}
Method: GET
Policies:
- DynamoDBReadPolicy:
TableName: !Ref UsersTable
CreateUserFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/createUser/
Handler: index.handler
MemorySize: 512
Events:
CreateUser:
Type: Api
Properties:
RestApiId: !Ref ApiGateway
Path: /users
Method: POST
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref UsersTable
UsersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: Users
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
- AttributeName: userId
AttributeType: S
- AttributeName: email
AttributeType: S
KeySchema:
- AttributeName: userId
KeyType: HASH
GlobalSecondaryIndexes:
- IndexName: EmailIndex
KeySchema:
- AttributeName: email
KeyType: HASH
Projection:
ProjectionType: ALL
Outputs:
ApiEndpoint:
Description: API Gateway endpoint
Value: !Sub 'https://${ApiGateway}.execute-api.${AWS::Region}.amazonaws.com/prod'Pattern 3: Cloud-Native Networking
# AWS VPC with best practices
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = "production-vpc"
cidr = "10.0.0.0/16"
# Multi-AZ deployment
azs = ["us-east-1a", "us-east-1b", "us-east-1c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
database_subnets = ["10.0.201.0/24", "10.0.202.0/24", "10.0.203.0/24"]
# NAT Gateways for private subnets
enable_nat_gateway = true
single_nat_gateway = false # Multi-AZ NAT for HA
one_nat_gateway_per_az = true
# DNS
enable_dns_hostnames = true
enable_dns_support = true
# VPC Flow Logs for security
enable_flow_log = true
create_flow_log_cloudwatch_iam_role = true
create_flow_log_cloudwatch_log_group = true
# Tags for cost allocation
tags = {
Environment = "production"
ManagedBy = "terraform"
Team = "platform"
}
}
# VPC Peering for cross-VPC communication
resource "aws_vpc_peering_connection" "main" {
vpc_id = module.vpc.vpc_id
peer_vpc_id = var.peer_vpc_id
auto_accept = true
tags = {
Name = "production-to-shared-services"
}
}
# Transit Gateway for hub-and-spoke
resource "aws_ec2_transit_gateway" "main" {
description = "Central transit gateway"
default_route_table_association = "enable"
default_route_table_propagation = "enable"
dns_support = "enable"
vpn_ecmp_support = "enable"
tags = {
Name = "production-tgw"
}
}
# Private Link for AWS services
resource "aws_vpc_endpoint" "s3" {
vpc_id = module.vpc.vpc_id
service_name = "com.amazonaws.${var.region}.s3"
route_table_ids = module.vpc.private_route_table_ids
tags = {
Name = "s3-endpoint"
}
}Resource Files
For detailed guidance on specific topics, see:
Cloud Platforms
- aws-patterns.md - Comprehensive AWS services guide (EC2, S3, RDS, Lambda, EKS), Well-Architected Framework, service selection
- azure-patterns.md - Azure services guide (VMs, Blob Storage, AKS, Functions), Azure best practices
- gcp-patterns.md - GCP services guide (Compute Engine, Cloud Storage, GKE, Cloud Functions), Google Cloud best practices
- oci-patterns.md - Oracle Cloud Infrastructure guide (Compute Instances, Object Storage, Autonomous Database, OKE), OCI best practices
Cloud Strategies
- multi-cloud-strategies.md - Multi-cloud vs single cloud, abstraction layers, service selection, trade-offs
- cloud-cost-optimization.md - Reserved instances, spot instances, right-sizing, tagging, FinOps principles
- migration-strategies.md - 6 R's of migration, migration patterns, modernization, assessment tools
Networking & Security
- cloud-networking.md - VPC design, peering, transit gateway, private link, DNS, CDN configuration
- cloud-security.md - IAM best practices, encryption (KMS), compliance (HIPAA, PCI-DSS), security controls
- cleared-cloud-environments.md - Government cloud regions (AWS GovCloud, Azure Government, GCP Gov, OCI Gov), air-gapped deployments, FedRAMP, CMMC, classified environments
- cloud-security-tools.md - CSPM tools (Trend Micro Cloud One, Prisma Cloud, Wiz, Aqua), native cloud security (Security Hub, Defender, SCC), tool comparison
Architecture Patterns
- well-architected-frameworks.md - AWS/Azure/GCP Well-Architected pillars, design principles, review process
- serverless-patterns.md - Lambda/Cloud Functions, API Gateway, event-driven architecture, FaaS best practices
Best Practices
Cloud Architecture
- Design for Failure:
- Assume everything fails
- Use multiple availability zones
- Implement health checks and auto-recovery
- Test failure scenarios regularly
- Security First:
- Implement least privilege access
- Enable encryption everywhere
- Use managed identity services
- Regular security audits and updates
- Cost Management:
- Tag all resources for cost allocation
- Use auto-scaling to match demand
- Leverage reserved capacity for predictable workloads
- Regular cost reviews and optimization
Service Selection
- Managed Services First:
- Prefer managed services over self-managed
- Reduces operational overhead
- Built-in high availability and backup
- Auto-patching and updates
- Right-Size Resources:
- Start small, scale as needed
- Monitor and adjust based on metrics
- Use burstable instances for variable workloads
- Consider serverless for intermittent loads
- Regional Selection:
- Deploy close to users (latency)
- Consider data residency requirements
- Check service availability by region
- Plan for disaster recovery region
Multi-Cloud Strategy
- Avoid Lock-In:
- Use containers and Kubernetes
- Abstract cloud-specific services
- Infrastructure as Code (portable)
- Standard protocols and APIs
- Choose Best-of-Breed:
- AWS for breadth of services
- Azure for Microsoft integration
- GCP for data analytics and ML
- OCI for Oracle Database and cost efficiency
- Hybrid for on-premises integration
- Operational Complexity:
- Balance benefits vs complexity
- Unified monitoring and logging
- Centralized identity management
- Consistent security policies
Anti-Patterns to Avoid
❌ Single region deployment - No disaster recovery capability ❌ No auto-scaling - Manual scaling is error-prone and slow ❌ Ignoring costs - Leads to cloud bill shock ❌ Over-provisioning - Wastes money on unused resources ❌ No tagging strategy - Impossible to track costs and ownership ❌ Tight cloud coupling - Creates vendor lock-in ❌ Manual deployments - Error-prone and not repeatable ❌ No monitoring - Can't detect or resolve issues ❌ Weak IAM policies - Security vulnerabilities ❌ No backup strategy - Risk of data loss
Common Tasks
Task: Deploy Serverless Application
- Design API endpoints and data model
- Create Lambda functions with proper IAM roles
- Set up API Gateway with authentication
- Configure DynamoDB tables with indexes
- Implement CloudWatch monitoring and alarms
- Set up CI/CD pipeline for deployments
- Test with load testing tools
- Document API and operational runbooks
Task: Implement Multi-Region Architecture
- Choose primary and secondary regions
- Design global networking (Route 53, CDN)
- Set up VPC in each region
- Implement database replication
- Configure load balancers and auto-scaling
- Set up health checks and failover
- Test failover scenarios
- Document disaster recovery procedures
Task: Optimize Cloud Costs
- Enable cost allocation tags
- Analyze current spending patterns
- Identify unused or underutilized resources
- Right-size instances based on metrics
- Purchase reserved capacity for steady workloads
- Implement auto-scaling for variable loads
- Use spot instances for fault-tolerant workloads
- Set up cost budgets and alerts
Integration Points
This skill integrates with:
- platform-engineering: Kubernetes on cloud (EKS, AKS, GKE), infrastructure automation
- devsecops: Cloud security scanning, IAM policies, compliance
- sre: Cloud monitoring, incident response, reliability engineering
- release-engineering: Cloud CI/CD services, artifact storage
- systems-engineering: Cloud networking, performance tuning, troubleshooting
Triggers and Activation
This skill activates when you:
- Work with cloud service providers (AWS, Azure, GCP, OCI)
- Design cloud-native architectures
- Implement serverless applications
- Optimize cloud costs
- Plan cloud migrations
- Configure cloud networking or security
- Use cloud-specific IaC (CloudFormation, ARM templates, Terraform)
Next Steps
For your specific task:
- Identify which cloud provider best fits your needs
- Review the relevant patterns and Well-Architected principles
- Choose appropriate services and architecture
- Implement with Infrastructure as Code
- Test in development environment first
- Monitor costs and performance continuously
Total Resources: 11 detailed guides covering all aspects of cloud engineering Pattern Library: 125+ production-tested cloud patterns across AWS, Azure, GCP, and OCI Maintained by: Cloud Engineering team based on real-world production experience
In this repository24 other files it gives its agents.
- api-engineeringSkill
- backend-dev-guidelinesSkill
- budget-and-cost-managementSkill
- build-engineeringSkill
- cybersecuritySkill
- database-engineeringSkill
- devsecopsSkill
- documentation-as-codeSkill
- engineering-managementSkill
- engineering-operations-managementSkill
- error-trackingSkill
- frontend-dev-guidelinesSkill
- general-it-engineeringSkill
- infrastructure-architectureSkill
- infrastructure-strategySkill
- network-engineeringSkill
- observability-engineeringSkill
- platform-engineeringSkill
- release-engineeringSkill
- route-testerSkill
- skill-developerSkill
- sreSkill
- systems-engineeringSkill
- technical-leadershipSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

