← ClaudeAtlas

sota-cloud-infrastructurelisted

State-of-the-art cloud infrastructure architecture (2026). Applies when designing, building, or auditing cloud environments on AWS, GCP, or Azure — account/project structure and landing zones, IAM and workload identity, VPC/network design, DNS/TLS/CDN, compute selection (serverless vs containers vs Kubernetes vs VMs), object storage and backup architecture, cost engineering (FinOps), and disaster recovery. Trigger keywords: cloud, AWS, GCP, Azure, Kubernetes, EKS, GKE, AKS, VPC, subnet, IAM, role, service account, serverless, Lambda, Cloud Run, Fargate, Terraform architecture, DNS, CDN, load balancer, FinOps, cost, rightsizing, disaster recovery, RTO, RPO, multi-region. Use for BOTH greenfield design and auditing existing infrastructure.
martinholovsky/SOTA-skills · ★ 8 · DevOps & Infrastructure · score 75
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA Cloud Infrastructure ## Purpose This skill encodes the 2026 state of the art for cloud infrastructure architecture: organizational structure, identity, networking, compute selection, data placement, cost, and resilience. Every rule exists to prevent a real failure class — blast-radius spread, credential theft, public data exposure, egress bill shock, unmeetable RTOs, or a Kubernetes cluster nobody needed. Boundaries with sibling skills — reference, do not duplicate: - **sota-devsecops** owns CI/CD pipelines, IaC scanning, Terraform state security, GitOps. - **sota-sandboxing** owns container/runtime hardening (seccomp, rootless, distroless). - **sota-observability** owns monitoring, alerting, SLOs, tracing. - **sota-databases** owns database engine selection, schema, and query design. - **sota-secrets-management** owns secret storage and rotation mechanics. This skill owns: what accounts/networks/identities/compute/storage exist, how they connect, what they cost, and how they survive failure. ## BUILD mode Use when designing or extending cloud infrastructure (architecture docs, Terraform modules, landing zones, network plans, DR plans). 1. Establish context before proposing anything: provider(s), org maturity (single account vs landing zone), environment count, data sensitivity, RTO/RPO targets, monthly spend ballpark, team size. A 3-person startup and a regulated enterprise get different answers from the same rules. 2. Read the matching rules files fro