/sota-cloud-infrastructure

name: sota-cloud-infrastructure
description: >-
  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.

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](../sota-devsecops/SKILL.md)** owns CI/CD pipelines, IaC scanning, Terraform state security, GitOps.
• **[sota-sandboxing](../sota-sandboxing/SKILL.md)** owns container/runtime hardening (seccomp, rootless, distroless).
• **[sota-observability](../sota-observability/SKILL.md)** owns monitoring, alerting, SLOs, tracing.
• **[sota-databases](../sota-databases/SKILL.md)** owns database engine selection, schema, and query design.
• **[sota-secrets-management](../sota-secrets-management/SKILL.md)** 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 from the index below BEFORE writing config. Compute selection ([rules/04](rules/04-compute-selection.md)) comes before networking details; account structure ([rules/01](rules/01-org-accounts-governance.md)) comes before everything. 3. Default to the boring, managed, restrictive option: managed services over self-hosted, private over public, multi-AZ over single-AZ, deny-by-default IAM and network policy. Every loosening gets a written justification in a comment. 4. Every resource you design must carry: owner tag, environment tag, cost-allocation tag, and a deletion/lifecycle story. Untagged infrastructure is unaccountable infrastructure. 5. State the cost and the failure mode of what you propose. "Three NAT gateways at per-hour + per-GB rates" and "this is single-region; region loss means restore from backup" belong in the design, not in the postmortem. The cost traps and levers are in [rules/06](rules/06-cost-finops.md). 6. Produce infrastructure as code (Terraform/OpenTofu/Pulumi fragments), never console-click instructions, except for one-time org bootstrap steps which must be documented as such.

AUDIT mode

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Use when reviewing existing cloud environments, Terraform repos, or architecture docs.

Process: inventory what exists (accounts/projects, networks, identities, compute, storage, DNS); walk the Audit checklist at the end of each relevant rules file; report findings in the format below. Confirm exploitability/reality before reporting — read the actual policy JSON or Terraform, don't infer from resource names.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | **Critical** | External party can read/modify data or assume identity now | Public S3/GCS bucket with sensitive data; IAM role assumable by `*` or any OIDC subject; security group `0.0.0.0/0` on a database port; root/owner account without MFA; cross-account trust to an unknown account | | **High** | One credential or insider step from compromise, or guaranteed outage class | Long-lived IAM user keys for humans or CI; wildcard `Action:*` on broad resources; single-AZ stateful workload with no tested backup; no SCPs/org policies on a multi-account org; flat network with no egress control; unencrypted snapshots shared externally | | **Medium** | Weakens containment, recovery, or cost control | Shared account for prod and non-prod; no permission boundaries on delegated admins; backups in same account/region as source; no cost allocation tags; NAT for traffic that should use private endpoints; cert renewal manual | | **Low** | Hygiene, drift, headroom | Inconsistent tagging; unused elastic IPs/disks; default VPC still present; missing IPv6 plan; quota headroom unmonitored |

Severity is judged by reachability (anonymous > authenticated external > tenant > insider) × impact (data/identity compromise > availability > cost). Cost-only findings cap at High (sustained material burn) and are usually Medium.

Finding format

[SEVERITY] <short title>
Where: <account/project> / <resource or Terraform address> / <file:line if IaC>
Evidence: <the exact policy statement / CIDR / config proving it>
Impact: <who can do what, or what fails and how>
Fix: <specific change — policy JSON / Terraform diff / architecture move>
`