Multi-Cloud vs Single-Cloud Strategy Analysis Prompt Template

This prompt is for cloud architects, CTOs, and platform engineering leads who need a structured, evidence-based comparison between a multi-cloud and single-cloud strategy. It forces the model to evaluate options across standard architectural dimensions—resilience, cost, operability, talent, and vendor leverage—rather than producing a generic recommendation. Use it before committing to a cloud provider strategy, when preparing a board-level decision memo, or when a team is advocating for multi-cloud without clear justification. The output is designed to be reviewed by humans, not deployed automatically. This is a decision-support prompt, not an automation prompt.

Do not use this prompt when you need a simple pros-and-cons list, a cost calculator, or a definitive answer. The prompt is designed to surface trade-offs and hidden assumptions, not to make the decision for you. It is also inappropriate for teams that have already committed to a strategy and are seeking post-hoc justification. The prompt requires the user to provide concrete context about their workload profiles, team capabilities, regulatory constraints, and growth projections. Without this context, the analysis will be shallow and unreliable. For regulated industries, always pair the output with a human review step and document the decision rationale separately.

Before running this prompt, gather your specific inputs: current and projected workload characteristics, latency and data residency requirements, team size and cloud expertise, existing vendor relationships, and any compliance constraints. The more concrete your inputs, the more actionable the analysis. After receiving the output, use the built-in evaluation criteria to check for common failure modes like premature multi-cloud abstraction, unstated assumptions about portability, or underestimation of operational complexity. The next step is to review the analysis with your engineering and finance stakeholders, challenge the assumptions, and document the final decision in an Architecture Decision Record (ADR).

The prompt below is designed to produce a rigorous, dimension-by-dimension comparison of a single-cloud and a multi-cloud strategy for a specific organizational context. It forces the model to consider resilience, negotiation leverage, operational complexity, talent, and cost before making a recommendation. Copy the entire code block, replace every square-bracket placeholder with your concrete details, and run it in a model with strong reasoning capabilities such as GPT-4, Claude 3.5, or Gemini 1.5 Pro.

codeCopy
You are a principal cloud architect advising the CTO of [COMPANY_NAME], a [COMPANY_SIZE] company in the [INDUSTRY] sector. Our current cloud footprint is primarily on [PRIMARY_CLOUD_PROVIDER], and we are evaluating whether to adopt a multi-cloud strategy by adding [SECONDARY_CLOUD_PROVIDER_OPTIONS] or to deepen our investment in a single-cloud approach.

Generate a structured trade-off analysis memo with the following sections:

1. **Executive Summary**: A 3-4 sentence summary of the recommendation and the single most important trade-off.
2. **Context and Constraints**: Summarize the business and technical context using these facts:
   - Current annual cloud spend: [ANNUAL_CLOUD_SPEND]
   - Primary workloads: [PRIMARY_WORKLOADS]
   - Regulatory requirements: [REGULATORY_REQUIREMENTS]
   - Existing team expertise: [TEAM_CLOUD_EXPERTISE]
   - Growth forecast: [GROWTH_FORECAST]
3. **Dimension-by-Dimension Comparison**: For each dimension below, provide a rating (Strong Advantage Single-Cloud / Slight Advantage Single-Cloud / Neutral / Slight Advantage Multi-Cloud / Strong Advantage Multi-Cloud) and a concise evidence-based rationale:
   - Resilience and Disaster Recovery
   - Negotiation Leverage and Cost Optimization
   - Operational Complexity and Tooling
   - Talent Acquisition and Team Capability
   - Feature Access and Innovation Speed
   - Compliance and Data Residency
   - Vendor Lock-In Risk
4. **Critical Assumptions**: List 3-5 assumptions that, if proven false, would invalidate the recommendation.
5. **Recommendation**: State a clear recommendation (Single-Cloud First, Purposeful Multi-Cloud, or Full Multi-Cloud Abstraction) with a phased implementation approach.
6. **Rejection Criteria**: Describe the conditions under which the recommended strategy should be reconsidered.

[CONSTRAINTS]
- Do not recommend a full multi-cloud abstraction layer unless there is a proven need for workload portability across providers.
- If operational maturity is low, bias toward single-cloud with selective multi-cloud for specific capabilities.
- Cite specific services from the named providers where relevant.
- Flag any recommendation that would require hiring more than [MAX_NEW_HIRES] new specialists as high-risk.

After running the prompt, validate the output against the [OUTPUT_SCHEMA] defined in your application harness. If the model fails to produce all six required sections or uses a rating outside the specified scale, retry with a stricter format instruction. For high-stakes decisions, route the generated memo to a human cloud architect for review before it enters any formal decision process. Do not treat this output as a final decision—only as structured input to a human-led architecture review.

This prompt is designed for a single-turn, zero-shot generation. Do not use it in a multi-turn chat without resetting context, as the model may drift toward advocating for one option. For production use, wrap this prompt in a function that validates the output JSON schema before showing it to a user. If the output fails validation, retry once with the validation error appended to the prompt. Log every output for auditability, as cloud strategy decisions have long-term financial and operational consequences. This prompt does not require tool calling, retrieval, or external APIs. Human review is mandatory before any decision is made.

Validation and Retry Logic: Define a strict JSON schema that matches the expected output structure (dimensions array, scores, rationale, risks, and recommendation). After the model responds, parse the output and validate it against this schema. If validation fails, construct a retry prompt that includes the original input, the malformed output, and the specific validation error message. Example retry instruction: Your previous output failed schema validation with error: [ERROR]. Please regenerate the complete analysis following the exact output schema. Limit retries to one attempt to avoid infinite loops. If the retry also fails, surface the raw output and validation error to the human reviewer with a clear flag that automated parsing failed.

Logging and Audit Trail: Log the full prompt, model response, validation result, and reviewer decision to an immutable audit store. Include metadata: timestamp, model version, temperature setting, user ID, and the specific [INPUT] variables used. This is critical because cloud strategy decisions involve multi-year cost commitments and architectural constraints. If a decision is later questioned, the audit trail must show exactly what analysis the model produced and what the human reviewer decided. Never log sensitive financial data or credentials that may appear in the [INPUT] context—sanitize inputs before logging.

Model Choice and Configuration: Use a model with strong reasoning capabilities and reliable JSON output (e.g., GPT-4o, Claude 3.5 Sonnet). Set temperature to 0.0 or a very low value (0.1) to maximize consistency across runs. Enable structured output mode if the model provider supports it (e.g., OpenAI's response_format with a JSON schema, or Anthropic's tool-use with a defined output schema). Do not use models smaller than ~70B parameters for this task, as the analysis requires holding multiple trade-off dimensions in context simultaneously. Smaller models frequently drop dimensions or produce inconsistent scoring.

Human Review Integration: Route every model output to a review queue before any decision is made. The review interface should display: (1) the original input context, (2) the model's structured analysis with all dimensions and scores, (3) any validation warnings or retry flags, and (4) a required approval/rejection action with a mandatory comment field. The reviewer must confirm that the analysis is balanced, the scores are justified, and no critical dimension was omitted. If the reviewer rejects the analysis, capture the rejection reason and consider whether the prompt needs refinement or the input context was insufficient.