The architecture design took two hours. The documentation took five days.
You know exactly how it goes. The technical design is done by Tuesday morning — the components, the tradeoffs, the reasoning. It's clear in your head and clear on the whiteboard. Then you spend the rest of the week writing the RFC the engineering org expects, the executive summary the CTO needs before approving budget, the migration plan with the risk register and rollback strategy, the cost justification deck for the CFO, and the security review doc before anything gets near production. The design was the interesting part. The paperwork is what's blocking everything else.
This is the part of cloud architecture work that doesn't show up in job descriptions but consumes a disproportionate share of your time. Architecture Decision Records. Executive cloud spend proposals. Well-Architected Review findings. Migration plans. RFC drafts. Cost optimization reports. Every one of these documents requires technical precision and the ability to communicate to a non-technical audience simultaneously — a combination that takes time even when you know exactly what you're trying to say.
Claude AI for cloud architects is specifically about that documentation and communication burden. Not the infrastructure. Not the design work. The writing.
What Claude Actually Does for Cloud Architects
If you've looked at AI tooling in the cloud space, the natural skepticism is: can this thing access my AWS account? Can it read my Terraform state? Does it touch my infrastructure?
The answer is no — and that's the correct answer for most enterprise environments.
Claude is a documentation and communication layer, not an infrastructure tool. It cannot query your AWS, GCP, or Azure accounts. It cannot read your Terraform state files, run CLI commands, or access anything in your cloud environment. It has no knowledge of your specific account, your deployed resources, or your cost data unless you paste that information into the conversation.
What it can do: take your bullet notes, raw findings, cost numbers, and rough technical thinking, and turn them into production-quality documentation. You provide the technical judgment and the architecture decisions. Claude drafts the document.
For enterprises with strict data governance policies, this is a feature. You control exactly what information Claude sees. You paste sanitized summaries and aggregated data, not raw account exports or sensitive infrastructure details. The technical judgment — the design, the tradeoffs, the risk assessment — stays with you. Claude handles the prose.
This works well alongside the tooling cloud architects already use. DevOps engineers use the same approach for runbooks and incident documentation. Software engineers use it for technical specs and code documentation. The pattern is the same: you do the technical work, Claude drafts the write-up.
1. Architecture Decision Records (ADRs)
ADRs are one of the highest-value artifacts in any engineering organization and one of the most consistently underdocumented. The decision gets made in a Zoom call. Someone writes "we went with Aurora over DynamoDB" in a Confluence comment. Six months later, nobody can reconstruct why.
A good ADR has a standard structure: context (why this decision was needed), decision (what was chosen), rationale (why), consequences (what changes as a result), and alternatives considered (what was evaluated and rejected). Writing that from scratch when you'd rather be building something is a friction point that causes ADRs to not get written at all.
Claude turns your bullet notes into a complete ADR in one pass. Paste what you know — options considered, the decision you made, your reasoning — and ask for the formatted output.
I need to write an Architecture Decision Record. Here are my raw notes:
Decision needed: [what architectural question this resolves]
Context: [why this decision was needed — what changed, what problem it solves]
Options we evaluated:
- Option A: [name and brief description]
- Option B: [name and brief description]
- Option C: [name and brief description, if applicable]
Decision: [what we chose]
Reasons for this decision:
- [bullet 1]
- [bullet 2]
- [bullet 3]
Tradeoffs we accepted:
- [what we're giving up or taking on by making this choice]
Draft a complete ADR in the standard format:
- Title (ADR-NNN: descriptive name)
- Status: Accepted
- Context
- Decision
- Rationale
- Consequences (positive and negative)
- Alternatives Considered (one section per alternative with why it was rejected)
Write it in a tone appropriate for a technical audience. Be precise about tradeoffs — don't soften them.
The "don't soften tradeoffs" instruction matters. ADRs are most useful when they're honest about what was accepted in exchange for what was gained. Claude will hedge toward diplomatic language by default; telling it not to produces more useful documentation.
2. Executive Cloud Spend Proposals
The technical justification for a cloud investment is usually complete before anyone asks for it. You know why the Reserved Instance commitment is worth it, why the data transfer architecture changes save $2M annually, why the new managed service reduces operational overhead. The problem is that the justification is in technical terms, and the approval decision is made by people thinking in business terms.
An executive cloud spend proposal needs to lead with business impact — cost reduction, risk reduction, velocity improvement, competitive positioning — and put the technical architecture detail where it belongs: in the appendix, available for the reader who wants to go deeper, but not blocking the CTO or CFO from seeing the recommendation in the first two paragraphs.
Claude reliably produces this structure when you ask for it explicitly.
I need to write an executive proposal for the following cloud investment:
What we're proposing: [plain description of the infrastructure change or investment]
Cost: [total cost, broken down if relevant — upfront, monthly, annual]
What this replaces or improves: [current state that this changes]
Technical justification (paste your bullet notes):
- [bullet]
- [bullet]
- [bullet]
Business impact:
- Cost reduction: [estimated savings and how you calculated them]
- Risk reduction: [what risks this addresses]
- Operational improvement: [productivity, velocity, reliability gains]
- Timeline: [when this pays off]
Audience: CTO and CFO. Neither is deeply technical, but both are comfortable with numbers.
Draft an executive cloud spend proposal with:
1. Executive Summary (2 paragraphs max — lead with the business case, end with the recommendation and cost)
2. Business Impact (cost, risk, operational — specific numbers, not generalities)
3. Timeline and Milestones (when we start, when we see results)
4. Technical Appendix (the architecture detail for anyone who wants to go deeper)
Business impact first. Technical detail in the appendix. If I haven't given you enough numbers to be specific, use [PLACEHOLDER] and flag what I need to fill in.
The [PLACEHOLDER] instruction is practical for proposals where you're still finalizing numbers. You get a complete structural draft with clear callouts for what needs to be confirmed before the document goes out.
Startup founders use similar prompts for investor proposals — the same "business impact first, detail second" structure that gets executive proposals read rather than skimmed.
3. Well-Architected Review Findings
The AWS Well-Architected Framework review produces a structured set of findings across five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. GCP and Azure have equivalent frameworks. The findings themselves are generated by the review process. The work that takes time is turning raw findings into a structured document that prioritizes remediation, explains business impact, and creates a realistic roadmap.
Paste your raw WAR findings and ask Claude to structure them into a document your team can actually act on.
I've completed a Well-Architected Review. Here are my raw findings:
System reviewed: [name and brief description]
Review scope: [what was included/excluded]
Findings by pillar:
Operational Excellence:
- [finding 1: severity, description]
- [finding 2: severity, description]
Security:
- [finding 1: severity, description]
- [finding 2: severity, description]
Reliability:
- [finding 1: severity, description]
Performance Efficiency:
- [finding 1: severity, description]
Cost Optimization:
- [finding 1: severity, description]
- [finding 2: severity, description]
Draft a structured Well-Architected Review document with:
1. Executive Summary (2 paragraphs — what was reviewed, overall posture, top priorities)
2. Findings by Pillar (each finding with: description, business impact, severity, recommended remediation)
3. Severity-Ranked Finding List (all findings sorted Critical → High → Medium → Low, with one-line description each)
4. Remediation Roadmap (grouped by quarter: what to fix now, what to fix in 90 days, what to address in the next planning cycle)
Be direct about severity. If something is a Critical finding, say it clearly — don't soften it to avoid discomfort. The point of the review is to surface real risk.
The remediation roadmap structure is consistently the most useful part of this output for engineering teams. Findings without prioritization create analysis paralysis. A quarterly grouping makes the backlog actionable.
4. Migration Plans
Migration documentation is where architectural knowledge most often stays locked in one person's head. The lead architect knows the phases, the dependencies, the rollback strategy, the success criteria. That knowledge needs to be in a document before the migration starts — both because other people need to execute it and because the plan itself catches gaps that weren't obvious in the design.
Writing a full migration plan from scratch is a substantial document: timeline, phase breakdown, dependency map, risk register, rollback procedures, success criteria, communication plan. Claude drafts all of it from your high-level notes.
I need to write a migration plan. Here are my notes:
What we're migrating: [current state → target state]
Reason for migration: [why this is happening]
Migration approach: [lift-and-shift / re-platform / re-architect / other]
Phases (high level):
Phase 1: [description, rough timing]
Phase 2: [description, rough timing]
Phase 3: [description, rough timing]
Key dependencies:
- [dependency 1]
- [dependency 2]
Known risks:
- [risk 1]
- [risk 2]
Rollback approach: [how we get back to current state if something goes wrong]
Success criteria: [how we know the migration succeeded]
Draft a complete migration plan with:
1. Overview (what, why, scope, approach)
2. Phase Breakdown (for each phase: objectives, activities, duration, dependencies, exit criteria)
3. Risk Register (each risk with: description, likelihood, impact, mitigation, owner)
4. Rollback Strategy (trigger conditions and step-by-step rollback procedure)
5. Success Criteria and Validation
6. Communication Plan (who needs to know what, when)
Flag any section where my notes don't give you enough detail to be specific — use [NEEDS INPUT] so I can fill in the gaps.
The risk register format — likelihood, impact, mitigation, owner — is the part of migration plans most commonly written vaguely. Claude produces consistent structured entries across all risks when you specify the format explicitly.
5. RFC / Design Doc Drafts
RFCs are how engineering organizations build shared understanding and get alignment on technical decisions before implementation. A well-structured RFC reduces review cycles: the audience knows what problem is being solved, what's being proposed, what alternatives were evaluated, and what's still open. A poorly structured RFC generates back-and-forth that should have been resolved in the document.
The challenge is that writing an RFC well requires switching from architectural thinking (the design) to communication thinking (how to explain the design to people who weren't in the room). Claude handles the communication layer.
I need to draft an RFC for the following system design:
System / feature name: [name]
Problem being solved: [what problem this addresses — be specific]
Proposed solution (paste your design notes):
- [architecture description]
- [key components and how they interact]
- [data flow]
- [key technical decisions made]
Constraints and requirements:
- [performance requirements]
- [scalability requirements]
- [operational requirements]
- [security requirements]
Alternatives we evaluated:
- Alternative A: [description] — rejected because [reason]
- Alternative B: [description] — rejected because [reason]
Open questions (things not yet decided):
- [question 1]
- [question 2]
Proposed timeline: [rough phases and dates]
Draft an RFC in the standard format:
1. Summary (3–4 sentences — the problem, the solution, the key tradeoff)
2. Problem Statement (what's broken or missing, why now, what happens if we don't solve it)
3. Proposed Solution (detailed description — enough for an engineer to implement from this document)
4. Alternatives Considered (each alternative with reason for rejection)
5. Open Questions (framed as questions with context, not just a list)
6. Implementation Timeline
7. Appendix (diagrams, references, or additional detail that would interrupt flow in the main body)
The audience is senior engineers and staff engineers who will review this critically. Be technically precise. Don't over-explain basics.
The "be technically precise, don't over-explain basics" instruction is important for a senior engineering audience. Claude defaults to over-explaining when uncertain about audience technical level. Specifying the audience calibrates the output correctly.
For the compliance documentation that often accompanies RFC approvals in regulated industries, Claude AI for legal and compliance covers how to draft those supporting documents efficiently.
6. Cloud Cost Optimization Reports
AWS Cost Explorer, GCP Cost Management, Azure Cost Analysis — they all produce data. What they don't produce is a document your VP of Engineering or CFO can act on. Raw cost anomaly data in tabular format requires interpretation: what caused this, what's the impact, what should we do, and in what order?
A cloud cost optimization report translates that data into a business-facing document: findings ranked by impact, recommendations with specific actions and estimated savings, and a prioritized implementation plan that accounts for engineering effort, not just cost reduction potential.
I need to write a cloud cost optimization report. Here are my findings:
Current monthly spend: [total]
Analysis period: [date range]
Cost anomalies and optimization opportunities identified:
1. [Finding]: [description] — estimated monthly savings: [amount]
2. [Finding]: [description] — estimated monthly savings: [amount]
3. [Finding]: [description] — estimated monthly savings: [amount]
[continue for all findings]
Engineering effort to implement (rough):
- [Finding 1]: [low / medium / high effort]
- [Finding 2]: [low / medium / high effort]
Audience: VP Engineering and CFO. The CFO cares about dollars. The VP cares about engineering trade-offs.
Draft a cloud cost optimization report with:
1. Executive Summary (total optimization potential, top 3 recommendations, estimated implementation timeline)
2. Findings Ranked by Impact (each finding: what it is in plain terms, estimated monthly/annual savings, implementation effort, recommended action)
3. Quick Wins (high-savings, low-effort items that should be done first)
4. Implementation Roadmap (grouped by effort level and dependency order)
5. Projected Savings Timeline (month-by-month estimated savings as recommendations are implemented)
Lead with business impact, not technical detail. Translate service names to plain language where possible — "unused compute reservations" not "underutilized Reserved Instance coverage." Flag any numbers where my estimates are rough with [ESTIMATE].
The "translate service names to plain language" instruction consistently improves these reports for non-technical executives. "Underutilized Reserved Instance coverage" and "orphaned EBS snapshots" mean nothing to a CFO. "Prepaid compute we're not using" and "storage backups from deleted servers" are immediately actionable.
Why Claude Over ChatGPT for Cloud Architects
If you've used ChatGPT for documentation tasks, there are a few meaningful differences worth knowing for cloud architecture work specifically.
Context window. Claude's 100K+ context window handles full Terraform modules, large architecture diagrams described in text, complete RFC histories, and multi-document inputs without truncation. An RFC that references three prior ADRs and includes a full architecture description won't get cut off partway through. Large migration plans with extensive risk registers stay intact across the full document.
Conservative with technical claims. Claude caveats rather than fabricates when it's uncertain about service limits, pricing, or SLA details. For documents that get reviewed by engineering teams and sometimes go to clients or executives, you don't want confident-sounding hallucinations about AWS service quotas or GCP pricing tiers. Claude flags uncertainty rather than inventing specifics.
Claude Projects for workstreams. Create one project per architecture engagement: the migration workstream, the new service design, the annual Well-Architected review. Load the relevant ADRs, the architecture principles, the RFC template your org uses. Every document produced in that project reflects your organization's specific standards and terminology automatically, without re-explaining them each session.
Structured output fidelity. ADRs, RFCs, and executive summaries require consistent formatting across a document and across multiple documents in the same workstream. Claude holds structure reliably — an ADR that starts in the right format stays in the right format, risk register entries that start consistent stay consistent.
No infrastructure access — and why that matters. Claude cannot access your cloud account, run CLI commands, read your Terraform state, or touch your infrastructure. For enterprises with strict data governance requirements, this means there's no question about what the tool can see. You control exactly what information goes in. The technical judgment, the architecture decisions, the cost analysis — those stay with you. Claude drafts the documentation.
Four Practical Tips
1. One Project per architecture workstream, not per document. In Claude Projects, create one project for the migration and load all relevant context: the current-state architecture, the target-state design, the constraints, your org's RFC template. Don't create a new project for each document — the persistent context is the whole point. Everything Claude produces in that project reflects the full workstream context automatically.
2. Paste bullet notes and constraints first; let Claude draft; then edit for accuracy. Claude works best as a first-draft engine, not an editor. Give it your bullet points and constraints, get the structured draft back, then edit for technical accuracy. This workflow is faster than writing from scratch and faster than trying to polish a draft in real-time.
3. For executive proposals, always specify "business impact first, technical detail second." Claude defaults to technical framing when the input is technical. If you don't explicitly ask for business-first framing, you'll get a proposal that leads with architecture choices rather than cost savings. The explicit instruction consistently produces more readable executive-facing documents.
4. Batch your documentation debt at the end of a sprint. At the end of a two-week sprint, dump your Slack threads, meeting notes, and rough bullet points into Claude and ask for a full set of documentation — ADRs for decisions made, an RFC for the design that shipped, an updated migration plan reflecting what changed. Thirty minutes of batched documentation work covers what would otherwise take days spread across the following sprint. The fresh context from the sprint means Claude has enough material to produce useful first drafts even from rough notes.
Get More Prompts
The six prompts above cover the highest-frequency documentation tasks in cloud architecture work. If you want a full library of copy-paste prompts for technical and executive communication — including deeper templates for the workstreams cloud architects deal with most — The Complete Claude Playbook is $27 and available as an instant PDF download.
View The Complete Claude Playbook or get it now — 100+ prompts covering the documentation and communication workflows where Claude saves the most time for technical professionals.