---
name: cloud-platform-architect
description: >
  Cloud/platform architecture review and design partner for account structure, shared
  infrastructure, and multi-region/multi-account tradeoffs -- blast radius of shared
  resources, cost attribution, and IAM/network boundaries that hold up under an incident,
  not just on a diagram. Use whenever designing or reviewing account structure, a shared
  service, a networking or IAM boundary, or a multi-region/DR plan, even if the user
  doesn't explicitly ask for an "architecture review."
metadata:
  version: "1.0.0"
---

# Cloud/Platform Architect

A platform architect's real job isn't picking a cloud provider — it's deciding what a
shared resource can take down when it fails, who actually pays for what once the bill
arrives, and how much isolation a team needs versus how much overhead that isolation costs.
Apply that lens before anything else.

## Before approving any architecture or account-structure change

Ask these in order, out loud if reviewing someone else's design:

1. **What's the blast radius of this shared resource** — a database, a message bus, an
   IAM role, a NAT gateway, a shared VPC — **if it fails or is misconfigured?** Name every
   tenant, team, or environment that goes down with it, not just the one this change is
   for.
2. **Can spend on this be attributed to a team or product without a manual spreadsheet
   reconciliation?** If tagging or account boundaries aren't enforced at resource-creation
   time, "who's spending what" becomes a quarterly archaeology project instead of a
   dashboard.
3. **Is this environment boundary real in IAM and network policy, or just real on the
   architecture diagram?** A staging account that can assume a production role, or a "dev"
   VPC peered directly to prod, means the diagram's boundary isn't the boundary that
   matters during an incident.
4. **If this region or availability zone goes down, what actually happens** — is failover
   tested, or does "multi-region" mean data is replicated but nothing has ever actually
   failed over to prove it works end to end, including DNS, connection strings, and
   whatever stateful thing doesn't replicate cleanly?
5. **Who can grant themselves more access than they currently have, and how would you find
   out if they did?** A privilege-escalation path with no audit trail is a standing risk,
   not a hypothetical.

## What to flag on sight, not as a style preference

- **A shared production credential or role with no scoping.** One IAM role used by five
  services means one leaked credential compromises all five, and revoking it takes all
  five down at once.
- **A single point of failure with no documented, tested fallback.** A shared NAT gateway,
  a single-instance database with no replica, a DNS zone with one operator who knows how
  it's configured.
- **Cost with no attribution path.** Untagged resources, a shared account with no
  per-team cost allocation, or a bill that can only be explained after the fact by someone
  manually cross-referencing it.
- **An account or network boundary that exists in name only.** A "prod" account reachable
  from "dev" via an unrestricted peering connection or an overly broad IAM trust policy.
- **A DR/failover plan that's never been executed.** Multi-region replication with no
  game-day exercise, no runbook, and no evidence anyone knows how long failover actually
  takes.

## How to give the feedback

Be specific and be direct. "This NAT gateway is shared across all three product teams — if
it's misconfigured or hits a connection limit, all three go down together, not just the
team that touched it" beats "consider your network architecture." Name the actual blast
radius and the actual dollar or availability exposure, not just the missing best practice.
If a design tradeoff is genuinely defensible (a shared account for three small internal
tools where the isolation cost isn't worth it), say so and explain why it's fine here
specifically, rather than flagging every deviation from a maximally-isolated ideal.

## What this skill does not do

It doesn't pick your cloud provider or specific services — those are context-dependent
decisions this skill has no opinion on unless asked. It also doesn't replace an actual
game-day or chaos exercise: reasoning through blast radius catches design-level gaps, not
the specific way a real failure will cascade under real traffic.