cloud-infrastructure（云基础设施）

ABOUTME: AWS/GCP cloud infrastructure patterns and best practices

ABOUTME: Well-Architected, security, cost optimization, observability

Cloud Infrastructure (AWS & GCP)

Quick Reference

# AWS
aws sts get-caller-identity
aws --profile staging ecs list-services

# GCP
gcloud auth list
gcloud config set project PROJECT_ID

# Security scanning
trivy config . && checkov -d .

See: terraform/SKILL.md | _PATTERNS.md

AWS Well-Architected (6 Pillars)

AWS ECS vs EKS

ECS Task Definition

resource "aws_ecs_task_definition" "app" {
  family                   = "app"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512
  container_definitions = jsonencode([{
    name   = "app"
    image  = "${var.ecr_repo}:${var.image_tag}"
    healthCheck = { command = ["CMD-SHELL", "curl -f http://localhost/health || exit 1"] }
  }])
}

GCP Cloud Run

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containerConcurrency: 80
      containers:
        - image: gcr.io/project/image
          resources: { limits: { cpu: "1", memory: "512Mi" } }

OS-Only Runtime (No Dockerfile)

Deploy pre-compiled binaries without Dockerfile or language-specific runtime. Uses google-24 stack with automatic OS security patching.

# Cross-compile (Go example, any compiled lang works)
GOOS=linux GOARCH=amd64 go build -o main ./cmd/app

# Deploy binary directly
gcloud beta run deploy SERVICE \
  --source . --no-build \
  --base-image=osonly24 \
  --project PROJECT_ID \
  --command ./main

When to use: Compiled binaries (Go, Dart, Rust), custom images built from scratch, or when you want auto-patching without maintaining a Dockerfile. Requires google-24 stack.

Cost Optimization

Compute: Reserved (72% savings), Spot (90%), Graviton, auto-scaling Storage: S3 Intelligent Tiering, lifecycle policies Networking: VPC endpoints (avoid NAT costs)

Observability (OpenTelemetry)

Why OTEL: Vendor-agnostic, unified traces/metrics/logs

receivers:
  otlp: { protocols: { grpc: { endpoint: 0.0.0.0:4317 } } }
processors:
  batch: { timeout: 1s }
exporters:
  awsxray: { region: us-east-1 }
service:
  pipelines:
    traces: { receivers: [otlp], processors: [batch], exporters: [awsxray] }

Networking

AWS VPC Design

VPC (10.0.0.0/16)
├── Public → ALB, NAT
├── Private → ECS/EKS, Lambda
└── Isolated → RDS (no internet)

VPC Endpoints

resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.${var.region}.s3"
}

Code Review Checklist

Resources

AWS: Well-Architected | Security Best Practices

GCP: Architecture Framework

Tools: Checkov | Infracost | OpenTelemetry