/cloud-architecture

name: cloud-architecture
description: Use when designing cloud infrastructure. Covers network topology, identity and least privilege, multi-AZ and multi-region trade-offs, managed versus self-hosted decisions, and designing for cost. Trigger on "design the aws setup for our new service", "do we need multi-region", "managed rds or run postgres ourselves". Do not use for application component design — see the system-design skill; for writing the infrastructure code, see the terraform skill.
metadata:
  category: devops
  version: 1.0.0
  tags: [cloud, aws, architecture, networking, iam]

Cloud Architecture

Purpose

Design cloud infrastructure that is secure by default, appropriately available, and whose cost is a consequence of deliberate decisions rather than a monthly surprise.

When to Use

• Designing infrastructure for a new system.
• Reviewing an existing architecture for security, availability, or cost.
• Deciding between managed services and self-hosting.
• Planning a multi-region or disaster-recovery strategy.

Capabilities

• Network topology: VPCs, subnets, gateways, private connectivity.
• Identity: least-privilege roles, federation, and eliminating long-lived keys.
• Availability design: multi-AZ, multi-region, RTO and RPO.
• Managed-versus-self-hosted evaluation.
• Cost modeling as a design input.

Inputs

• Workload characteristics: stateful or stateless, traffic shape, data gravity.
• Availability requirements, expressed as RTO and RPO, not adjectives.
• Compliance and data-residency constraints.
• Budget.

Outputs

• A network and identity design with least privilege by default.
• An availability posture matched to the stated RTO/RPO.
• A cost model with the drivers identified.

Workflow

1. **Start with the data** — Where it lives, who may see it, and how much it costs to move. Data gravity determines more of the architecture than compute does. 2. **Design the network for isolation** — Private subnets for compute and data; public exposure only through a load balancer or gateway. Nothing with a database on it should have a public IP. 3. **Grant least privilege** — Roles scoped to actions and resources. Wildcards in IAM policies are how a compromised container becomes a compromised account. 4. **Match availability to requirement** — Multi-AZ is cheap and should be the default for anything production. Multi-region is expensive, complex, and justified only by an RTO that genuinely demands it. 5. **Prefer managed services** — Unless you have a specific reason and the staff to operate the alternative. Self-hosting a database to save money usually costs more in engineer time within a year. 6. **Model the cost** — Egress, cross-AZ traffic, NAT gateways, and idle capacity are the surprises. Estimate them before building, not after the invoice.

Best Practices

• Least privilege is not an aspiration; it is a default. Start with no permissions and add what fails.
• Long-lived access keys are the most common cloud breach vector. Use roles, instance profiles, and OIDC federation — and set an organizational policy that forbids creating static keys.
• Cross-AZ data transfer costs money. A chatty service split across three AZs pays for every hop, and the bill is invisible until it is large.
• NAT gateways are billed per hour *and* per gigabyte. A workload pulling large images through NAT is a line item people find months later. Use VPC endpoints for AWS services.
• Multi-region active-active is one of the most expensive decisions available. It requires solving data replication, conflict resolution, and routing — for an availability gain most products do not need.
• Tag everything, from the first resource. Retrofitting tags for cost attribution across an existing account is a project.

Examples

**Least-privilege role: scoped to the action, the resource, and the condition:**

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOwnTenantObjectsOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::app-uploads/${aws:PrincipalTag/tenant_id}/*"
    },
    {
      "Sid": "WriteOwnTenantObjectsOnly",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::app-uploads/${aws:PrincipalTag/tenant_id}/*",
      "Condition": {
        "StringEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

Compare with `"Action": "s3:*", "Resource": "*"`, which is what most policies start as and far too many stay as.

**Cost drivers, identified at design time:**

Monthly estimate (eu-west-1, steady state):

  ECS Fargate    6 tasks x 1vCPU/2GB, 24/7          ~$180
  RDS Postgres   db.r6g.large, Multi-AZ             ~$430
  ALB            1 + ~2 TB processed                 ~$40
  NAT Gateway    2 AZs x $0.045/hr + 800 GB egress   ~$105   <-- surprise #1
  S3             400 GB + requests                    ~$12
  CloudWatch     Logs ingest 300 GB                   ~$150   <-- surprise #2
  Data transfer  cross-AZ chatter, ~1.5 TB            ~$15
                                                    -------
                                                     ~$932

Actions taken at design time:
  - S3 and ECR reached via VPC endpoints, not NAT: NAT egress drops to ~100 GB (-$65).
  - Log sampling for debug-level in production, 30-day retention: (-$95).
  Revised: ~$772/month, with the two largest surprises removed before they appeared.

Notes

• CloudWatch Logs ingestion is billed per gigabyte and is routinely the second- or third-largest line on a bill for a service that logs verbosely. Sample debug logs; keep errors.
• A single NAT gateway is a single point of failure; one per AZ is the resilient configuration and doubles the hourly cost. VPC endpoints avoid both problems for AWS-service traffic.
• "We might need multi-region later" is not a reason to build it now. It is a reason to keep state in one place and avoid decisions that m