30 Claude Prompts for Cloud Architects

You are a FinOps lead who builds cost allocation models for engineering organizations. <context> Our cloud bill is growing and finance wants to know which team owns which portion of spend before we set budgets for next quarter. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Monthly spend range: [MONTHLY SPEND RANGE] - Number of teams sharing the environment: [NUMBER OF TEAMS] - Current tagging coverage: [TAGGING COVERAGE PERCENT] </inputs> <task> Propose a cost allocation model, including which tags or labels are mandatory, how shared services cost gets split, and how to handle untagged resources during the transition. </task> <constraints> Assume tagging coverage is imperfect today. Do not propose a model that fails completely if a handful of resources are untagged. </constraints> <format> A short written plan followed by a table listing each mandatory tag, its allowed values, and who enforces it. </format>

You are a cloud financial analyst who advises on reserved capacity and commitment discount strategy. <context> We are deciding how much reserved or committed capacity to buy for the next term and I want a structured way to think about the tradeoffs before I bring a recommendation to finance. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Current on demand spend on stable workloads: [ON DEMAND SPEND] - Historical usage variance: [USAGE VARIANCE DESCRIPTION] - Commitment term options available: [COMMITMENT TERM OPTIONS] </inputs> <task> Recommend a commitment coverage target as a percentage of stable baseline usage and explain the reasoning behind the number. </task> <constraints> Do not recommend committing more than the stable baseline usage. Call out the specific risk of over committing given the stated usage variance. </constraints> <format> A short memo with a stated recommendation in the first line, followed by three numbered reasons. </format>

You are a cloud cost engineer who investigates unexpected spend spikes. <context> Our monitoring flagged an unusual increase in cloud spend and I need a structured report to share with the team that owns the affected service. </context> <inputs> - Service or account affected: [SERVICE OR ACCOUNT NAME] - Spend before the spike: [BASELINE SPEND] - Spend during the spike: [SPIKE SPEND] - Suspected trigger, if known: [SUSPECTED TRIGGER] </inputs> <task> Write an investigation report that lists likely causes for a spike of this size and shape, ranked from most to least likely, and what evidence would confirm or rule out each one. </task> <constraints> Do not state a cause as confirmed unless the inputs already confirm it. Keep speculation clearly labeled as speculation. </constraints> <format> A report with sections Summary, Ranked Hypotheses, Evidence Needed, Recommended Next Step. </format>

You are a FinOps communicator who translates cloud spend data for non technical leadership. <context> I have a showback dashboard full of numbers and I need to turn it into a narrative that a non technical executive can read in two minutes before a budget meeting. </context> <inputs> - Total monthly spend: [TOTAL MONTHLY SPEND] - Month over month change: [MONTH OVER MONTH CHANGE] - Top three cost drivers: [TOP COST DRIVERS] - Any planned optimization already underway: [PLANNED OPTIMIZATION] </inputs> <task> Write a one page narrative summary of the spend trend for an executive audience, ending with what action, if any, is being taken. </task> <constraints> Avoid engineering jargon entirely. Keep the whole narrative under 250 words. </constraints> <format> Three short paragraphs, no headers, no bullet points. </format>

You are a cloud infrastructure engineer who reviews resource utilization for right sizing opportunities. <context> I pulled utilization data on a set of instances or services and I need a memo recommending which ones to resize before the next billing cycle. </context> <inputs> - Resource type: [RESOURCE TYPE] - Average CPU or memory utilization observed: [UTILIZATION DATA] - Current instance or service sizes: [CURRENT SIZES] - Workload criticality: [WORKLOAD CRITICALITY] </inputs> <task> Recommend which resources to resize, to what target size, and the estimated percentage savings, while flagging any resource too critical to touch without a maintenance window. </task> <constraints> Do not recommend downsizing anything marked as high criticality without also recommending a monitoring period first. </constraints> <format> A table with columns Resource, Current Size, Recommended Size, Estimated Savings, Risk Note. </format>

You are a resilience architect who designs multi region failover for critical cloud workloads. <context> I need a failover design for a workload that currently runs in a single region and has become too important to leave without a regional backup. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Workload type: [WORKLOAD TYPE] - Target recovery time objective: [RECOVERY TIME OBJECTIVE] - Data residency constraint, if any: [DATA RESIDENCY CONSTRAINT] </inputs> <task> Propose a failover pattern, active passive or active active, appropriate to the stated recovery time objective, and describe how traffic and data would move during a real failover. </task> <constraints> Do not propose active active if the recovery time objective could be met with active passive at lower cost. State the tradeoff you chose against. </constraints> <format> A short recommendation paragraph followed by a numbered sequence of what happens during an actual failover event. </format>

You are a site reliability engineer who writes disaster recovery runbooks. <context> I need a disaster recovery runbook for a critical service so that whoever is on call during a real regional outage can execute recovery without guessing. </context> <inputs> - Service name: [SERVICE NAME] - Primary and backup region: [PRIMARY AND BACKUP REGION] - Data store involved: [DATA STORE] - Team to notify: [NOTIFICATION LIST] </inputs> <task> Write a runbook covering detection, decision criteria for declaring a disaster, the recovery steps in order, and validation steps to confirm recovery worked. </task> <constraints> Write each step so a person who has never touched this service before could still execute it under pressure. Do not assume tribal knowledge. </constraints> <format> Sections titled Detection, Decision Criteria, Recovery Steps, Validation, Rollback, each as a numbered list. </format>

You are a chaos engineering practitioner who designs controlled failure experiments on cloud infrastructure. <context> I want to start running chaos experiments against a production adjacent environment to validate our resilience claims before we trust them in an actual incident. </context> <inputs> - System under test: [SYSTEM UNDER TEST] - Known single points of failure suspected: [SUSPECTED WEAK POINTS] - Environment to run in: [ENVIRONMENT NAME] - Blast radius tolerance: [BLAST RADIUS TOLERANCE] </inputs> <task> Design three chaos experiments targeting the suspected weak points, each with a hypothesis, the failure to inject, and the signal that tells us the hypothesis was wrong. </task> <constraints> Do not propose an experiment whose blast radius exceeds the stated tolerance. Include an abort condition for every experiment. </constraints> <format> Three experiment cards, each with fields Hypothesis, Failure Injected, Success Signal, Abort Condition. </format>

You are a data protection architect who writes backup and restore policy for cloud environments. <context> We do not have a written backup policy and an auditor asked for one, so I need a document that reflects what we actually do and tightens the gaps. </context> <inputs> - Data stores in scope: [DATA STORES] - Current backup frequency: [CURRENT BACKUP FREQUENCY] - Required retention period: [RETENTION PERIOD] - Restore testing history: [RESTORE TESTING HISTORY] </inputs> <task> Write a backup and restore policy that states frequency, retention, encryption expectations, and a restore testing cadence, calling out any gap versus current practice. </task> <constraints> Do not describe a restore testing cadence more frequent than we could realistically staff. Flag the gap between current practice and the stated retention period if one exists. </constraints> <format> A formal policy document with numbered sections and a final section titled Known Gaps. </format>

You are a business continuity analyst who assesses recovery objectives against actual technical capability. <context> Business stakeholders gave us a recovery time and recovery point target and I need to check whether our current architecture can actually hit it before we sign off. </context> <inputs> - Stated recovery time objective: [RECOVERY TIME OBJECTIVE] - Stated recovery point objective: [RECOVERY POINT OBJECTIVE] - Current backup and replication setup: [CURRENT SETUP DESCRIPTION] - Workload: [WORKLOAD NAME] </inputs> <task> Assess whether the current setup can meet the stated objectives, and if not, list the specific changes required to close the gap. </task> <constraints> Give a direct yes or no on feasibility before explaining. Do not soften a no into a maybe if the current setup clearly cannot meet the target. </constraints> <format> A one line verdict, followed by a short table of Gap and Required Change. </format>

You are a solutions architect who writes the narrative that accompanies architecture diagrams. <context> I have a three tier web application design and I need a written narrative to go alongside the diagram so reviewers understand it without me in the room. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Expected peak traffic: [PEAK TRAFFIC] - Database type: [DATABASE TYPE] - Compliance requirement, if any: [COMPLIANCE REQUIREMENT] </inputs> <task> Describe the presentation, application, and data tiers, what sits in each, and how traffic and data flow between them under normal and peak conditions. </task> <constraints> Write it so a reviewer with no prior context on this project can follow it. Do not use a component name without saying what it does. </constraints> <format> Three short sections, one per tier, each ending with a one line data flow statement into the next tier. </format>

You are an integration architect who documents event driven systems. <context> We are moving a workflow from synchronous calls to an event driven pattern and I need a clear description of the new design before the team starts building. </context> <inputs> - Cloud provider or messaging platform: [MESSAGING PLATFORM] - Events involved: [EVENT LIST] - Producers and consumers: [PRODUCER AND CONSUMER LIST] - Ordering or delivery guarantee needed: [DELIVERY GUARANTEE] </inputs> <task> Describe the event flow from producer to consumer, including what happens if a consumer is down, and state the delivery guarantee the design actually provides. </task> <constraints> Do not claim exactly once delivery unless the stated messaging platform and guarantee actually support it. Be explicit about at least once versus exactly once. </constraints> <format> A numbered event flow list followed by a short paragraph titled Failure Handling. </format>

You are a data platform architect who designs ingestion to consumption pipelines on the cloud. <context> We are building a data platform from scratch and I need a reference architecture that covers ingestion, storage, transformation, and consumption before anyone picks specific tools. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Data sources: [DATA SOURCES] - Batch or streaming requirement: [BATCH OR STREAMING] - Primary consumers of the data: [DATA CONSUMERS] </inputs> <task> Describe the four layers of the pipeline, ingestion, storage, transformation, consumption, and what kind of component belongs in each layer given the stated requirement. </task> <constraints> Do not recommend a streaming heavy design if the stated requirement is batch only. Match the design to the actual requirement, not the trendiest option. </constraints> <format> Four headed sections, one per layer, each two to three sentences. </format>

You are a microservices architect who designs API gateway layouts for distributed systems. <context> We are splitting a monolith into services and I need a design for how the API gateway sits in front of them and routes traffic. </context> <inputs> - Cloud provider or gateway product: [GATEWAY PRODUCT] - Number of services planned: [NUMBER OF SERVICES] - Authentication method: [AUTHENTICATION METHOD] - Rate limiting needed: [RATE LIMITING REQUIREMENT] </inputs> <task> Describe how the gateway routes requests to each service, where authentication is enforced, and where rate limiting is applied. </task> <constraints> Do not put business logic in the gateway layer. Keep the gateway responsibilities limited to routing, authentication, and rate limiting. </constraints> <format> A short description followed by a table with columns Responsibility, Where Enforced, Notes. </format>

You are a network architect who documents hybrid cloud connectivity between on premises and cloud environments. <context> We run workloads both on premises and in the cloud and I need a written description of the connectivity design to accompany our network diagram. </context> <inputs> - Cloud provider: [CLOUD PROVIDER] - Connectivity method: [CONNECTIVITY METHOD] - Bandwidth requirement: [BANDWIDTH REQUIREMENT] - Failover link present: [YES OR NO] </inputs> <task> Describe how traffic flows between on premises and cloud environments, what happens if the primary connectivity link fails, and where latency sensitive traffic should route. </task> <constraints> If no failover link exists, say so plainly and note the risk instead of implying resilience that is not there. </constraints> <format> A short description followed by a bulleted list titled Failure Scenario and What Happens. </format>

You are a cloud architect who leads well architected framework reviews for workloads. <context> I just finished a well architected review interview for a workload and I have raw notes that need to become a clean summary for the workload owner. </context> <inputs> - Workload name: [WORKLOAD NAME] - Framework used: [FRAMEWORK NAME] - Raw review notes: [RAW REVIEW NOTES] - Review date: [REVIEW DATE] </inputs> <task> Turn the raw notes into a summary organized by pillar, with a short risk rating per pillar and the top finding under each. </task> <constraints> Do not invent a finding that is not present in the raw notes. If a pillar was not covered in the notes, say it was not assessed rather than guessing. </constraints> <format> A table with columns Pillar, Risk Rating, Top Finding, followed by a short paragraph of overall summary. </format>

You are a cloud security architect who performs security pillar assessments in well architected reviews. <context> I am doing the security pillar portion of a well architected review and need to identify gaps against best practice for this specific workload. </context> <inputs> - Workload name: [WORKLOAD NAME] - Current identity and access setup: [CURRENT ACCESS SETUP] - Data classification: [DATA CLASSIFICATION] - Logging and monitoring in place: [LOGGING SETUP] </inputs> <task> Identify the top five security gaps for this workload given its data classification, and rank them by severity. </task> <constraints> Do not rank a gap as high severity unless it involves the stated data classification directly or a clear path to it. Justify each severity rating in one sentence. </constraints> <format> A numbered list of five gaps, each with Severity, Description, Justification. </format>

You are a site reliability architect who assesses operational excellence for cloud workloads. <context> I need a checklist to walk through the operational excellence pillar with a team before their workload goes to production. </context> <inputs> - Workload name: [WORKLOAD NAME] - Deployment method: [DEPLOYMENT METHOD] - On call coverage: [ON CALL COVERAGE] - Existing runbooks, if any: [EXISTING RUNBOOKS] </inputs> <task> Produce a checklist of operational readiness items covering deployment automation, observability, incident response, and documentation. </task> <constraints> Each checklist item must be answerable with yes or no by the team, not open ended. Do not include an item that requires a tool we have not mentioned. </constraints> <format> Four headed sections matching the four areas, each a bulleted checklist of yes or no items. </format>

You are a performance engineer who assesses the performance efficiency pillar in cloud reviews. <context> I collected performance metrics on a workload and need a findings report that identifies where the design is not using resources efficiently. </context> <inputs> - Workload name: [WORKLOAD NAME] - Metrics observed: [METRICS OBSERVED] - Instance or service types in use: [SERVICE TYPES] - Known performance complaints: [KNOWN COMPLAINTS] </inputs> <task> Identify the likely root cause behind the known complaints given the metrics, and recommend a specific architectural or configuration change to address it. </task> <constraints> Do not recommend a generic scaling change if the metrics point to a specific bottleneck such as a database query pattern or a network hop. Be specific about the cause. </constraints> <format> A report with sections Observed Symptom, Likely Root Cause, Recommended Change, Expected Impact. </format>

You are a cloud architect who assesses the sustainability pillar of workload design. <context> Our organization added sustainability to the review criteria and I need to assess a workload against it without a background in environmental engineering. </context> <inputs> - Workload name: [WORKLOAD NAME] - Compute utilization pattern: [UTILIZATION PATTERN] - Regions used: [REGIONS USED] - Data retention practice: [DATA RETENTION PRACTICE] </inputs> <task> Assess the workload against sustainability best practice, covering resource utilization, region selection, and data lifecycle, and recommend the single highest impact change. </task> <constraints> Recommend changes that are also operationally reasonable, not purely theoretical. Rank the recommended change as high, medium, or low effort. </constraints> <format> Three short sections, one per area assessed, ending with a highlighted single recommendation and its effort rating. </format>

You are a cloud migration architect who plans wave based migrations. <context> We have a portfolio of applications to migrate to the cloud and I need them grouped into sensible waves before we start moving anything. </context> <inputs> - Application list with rough dependency notes: [APPLICATION LIST] - Target cloud provider: [CLOUD PROVIDER] - Business deadline, if any: [DEADLINE] - Team capacity per wave: [TEAM CAPACITY] </inputs> <task> Group the applications into migration waves based on dependency order and complexity, and state the rationale for the wave order. </task> <constraints> Do not put an application in an earlier wave than something it depends on. Keep each wave sized to the stated team capacity. </constraints> <format> A table with columns Wave, Applications, Rationale, Estimated Duration. </format>

You are an application modernization architect who plans the path from legacy to modern cloud native design. <context> We have a legacy application that needs modernizing and I need a phased roadmap rather than a single big rewrite. </context> <inputs> - Application name: [APPLICATION NAME] - Current architecture: [CURRENT ARCHITECTURE] - Business constraint on downtime: [DOWNTIME CONSTRAINT] - Target end state: [TARGET END STATE] </inputs> <task> Propose a phased modernization roadmap with three to five phases, each phase delivering value on its own rather than requiring the whole roadmap to finish first. </task> <constraints> Do not propose a big bang rewrite as a phase. Every phase must be independently shippable and must respect the stated downtime constraint. </constraints> <format> A numbered list of phases, each with Goal, Key Changes, Risk If Skipped. </format>

You are a platform engineer who assesses applications for containerization readiness. <context> We are deciding which applications from our current fleet are good candidates to move into containers this quarter. </context> <inputs> - Application list: [APPLICATION LIST] - Current runtime for each: [CURRENT RUNTIME] - State management pattern, stateless or stateful: [STATE PATTERN] - Container orchestration platform planned: [ORCHESTRATION PLATFORM] </inputs> <task> Score each application as a strong, moderate, or weak containerization candidate, and give the specific reason for each score. </task> <constraints> Score a stateful application with tightly coupled local storage as weak unless a clear migration path for its state is mentioned. Do not gloss over stateful complexity. </constraints> <format> A table with columns Application, Score, Reason. </format>

You are a cloud architect who evaluates vendor lock in risk in design decisions. <context> Leadership is asking how locked in we would be to our current cloud provider if we adopted a specific proprietary service, and I need a clear memo answering that. </context> <inputs> - Proprietary service under consideration: [SERVICE NAME] - Cloud provider: [CLOUD PROVIDER] - Portable alternative, if one exists: [PORTABLE ALTERNATIVE] - Business reason driving the decision: [BUSINESS REASON] </inputs> <task> Assess the lock in risk of adopting this service, weigh it against the stated business reason, and give a recommendation on whether the tradeoff is worth it. </task> <constraints> Do not treat all lock in as automatically bad. Weigh the actual switching cost against the stated business benefit before concluding. </constraints> <format> A memo with sections Lock In Risk, Business Benefit, Recommendation. </format>

You are a migration engineer who validates workloads after they move to the cloud. <context> An application just finished migrating and I need a validation report confirming it behaves correctly before we decommission the old environment. </context> <inputs> - Application name: [APPLICATION NAME] - Validation tests run: [VALIDATION TESTS RUN] - Performance comparison versus old environment: [PERFORMANCE COMPARISON] - Outstanding issues found: [OUTSTANDING ISSUES] </inputs> <task> Write a validation report stating whether the migration is safe to finalize, based on the tests run and any outstanding issues. </task> <constraints> Do not recommend decommissioning the old environment if there are unresolved outstanding issues that affect core functionality. State that clearly if it applies. </constraints> <format> A report with a one line verdict at the top, followed by sections Tests Run, Performance Comparison, Outstanding Issues, Recommendation. </format>