Hybrid Cloud Connectivity Architecture Prompt

This prompt is designed for network architects and cloud platform engineers who need a rigorous, pre-implementation review of a hybrid cloud connectivity design. The job-to-be-done is to systematically surface architectural risks—such as asymmetric routing, single-circuit dependencies, and encryption gaps—that are often overlooked in design documents and topology diagrams. The ideal user has a complete or near-complete design artifact, including a topology diagram and a written design document specifying bandwidth, routing protocols, and encryption standards. The prompt acts as an adversarial design partner, forcing a structured checklist of failure modes before procurement or configuration begins.

To use this prompt effectively, you must provide a detailed [DESIGN_DOCUMENT] and a description of your [TOPOLOGY]. The prompt is not a substitute for a live network assessment or a troubleshooting session for an active incident. It will not diagnose packet loss, BGP flapping, or real-time performance issues. Instead, it operates on static design intent. The required context includes explicit details about VPN gateways, Direct Connect or ExpressRoute circuits, BGP configurations, CIDR ranges, and intended traffic flows. Without this level of detail, the review will be shallow and may produce generic warnings rather than actionable, design-specific risks.

Do not use this prompt for reviewing simple, single-cloud deployments with a single VPN tunnel and no routing complexity. It is also inappropriate for auditing an existing, live production network where the goal is to find current misconfigurations. For those scenarios, an infrastructure-as-code review prompt or a live configuration audit tool is a better fit. The primary value here is in preventing future incidents by catching design flaws early. After running the review, you should expect to feed the findings directly into an architecture decision record (ADR) or a risk register, ensuring each identified risk has a documented mitigation or acceptance before the design is finalized.

This section provides the core prompt template for a Hybrid Cloud Connectivity Architecture Review. It is designed to be pasted directly into your AI workflow. The prompt instructs the model to act as a principal network architect and produce a structured analysis of a proposed or existing hybrid cloud connectivity design. The output is a detailed report covering topology, bandwidth, encryption, routing, and failure modes, formatted for direct use in a design review or Architecture Decision Record (ADR).

markdownCopy
You are a principal network architect reviewing a hybrid cloud connectivity design. Your task is to produce a structured, evidence-based analysis of the proposed architecture described in [DESIGN_DOCUMENT].

**Review Criteria:**
Analyze the design against the following dimensions. For each, provide a finding (Pass, Warning, Fail), a detailed explanation, and a concrete recommendation.

1.  **Topology and Redundancy:** Evaluate the physical and logical topology. Check for single points of failure in circuits, routers, and cloud on-ramps (Direct Connect, ExpressRoute, Interconnect). Assess the diversity of physical paths.
2.  **Bandwidth and Capacity Planning:** Analyze provisioned bandwidth against projected workload requirements from [CAPACITY_PLAN]. Check for burst handling, QoS policies, and headroom for failover scenarios.
3.  **Encryption and Authentication:** Verify the encryption standards for data in transit (IPsec parameters, MACsec, TLS). Review authentication methods (pre-shared keys, certificate-based) and key rotation procedures.
4.  **Routing Design and Asymmetry:** Examine the routing protocol configuration (BGP, static). Identify risks of asymmetric routing, suboptimal path selection, and route propagation delays. Check for MTU mismatches, especially across VPN tunnels and underlay networks.
5.  **Failure Mode Analysis:** Model the impact of a single circuit failure, a cloud on-ramp failure, and a complete region failure. Describe the expected failover behavior, convergence time, and any manual intervention required.

**Output Format:**
Produce a report in Markdown with the following sections:
- **Executive Summary:** A 3-4 sentence summary of the architecture's overall resilience and the top 3 risks.
- **Detailed Findings:** A table with columns: Dimension, Finding (Pass/Warning/Fail), Explanation, Recommendation.
- **Failure Mode Walkthroughs:** A narrative walkthrough for each failure scenario listed above.
- **Unanswered Questions:** A list of critical questions that cannot be answered from the provided [DESIGN_DOCUMENT] alone.

**Constraints:**
- Ground all findings in evidence from the [DESIGN_DOCUMENT].
- If information is missing, state it explicitly in the "Unanswered Questions" section rather than making assumptions.
- Use precise technical terminology appropriate for a senior network engineering audience.
- Flag any design that relies on a single physical circuit or virtual gateway as a critical risk.

To adapt this template, replace the [DESIGN_DOCUMENT] and [CAPACITY_PLAN] placeholders with your actual source material. The [DESIGN_DOCUMENT] should contain the full architecture description, including diagrams if described textually. The [CAPACITY_PLAN] is optional but critical for a meaningful bandwidth review. For high-risk production environments, always route the final output for human expert review before accepting any recommendations. You can extend the Review Criteria list with additional dimensions like cost analysis or compliance checks by adding numbered items to the prompt.

This prompt is designed to be embedded in a structured review pipeline, not used as a one-off chat. The primary integration point is a design review platform or CI/CD gate where network architecture proposals are submitted as structured documents. The application layer should collect the required inputs—network topology description, connectivity requirements, existing infrastructure details, and constraints—and assemble them into the prompt's [TOPOLOGY_DESCRIPTION], [CONNECTIVITY_REQUIREMENTS], [EXISTING_INFRASTRUCTURE], and [CONSTRAINTS] placeholders before invoking the model.

Validation and output handling: The model's response should be parsed against the expected output schema before it reaches a human reviewer. Implement a post-processing validator that checks for the presence of all required sections: bandwidth analysis, encryption assessment, routing evaluation, failure mode identification, and prioritized recommendations. Each finding must include a severity level and an evidence reference back to the input topology. If the output fails schema validation, retry once with the same prompt plus the validation errors appended as [PREVIOUS_OUTPUT_ERRORS]. After two failures, flag for human triage rather than looping indefinitely. Log every model invocation with the prompt version hash, input topology hash, output, validation result, and reviewer decision for auditability.

Model choice and tool integration: Use a model with strong technical reasoning capabilities and a context window large enough to hold the full topology description plus output schema. For complex topologies with multiple connectivity paths, consider splitting the review into per-path invocations and then running a synthesis pass. If your organization maintains a knowledge base of past architecture decisions or known failure patterns, wire in a retrieval step before prompt assembly to inject relevant [PRIOR_INCIDENTS] or [ORGANIZATIONAL_STANDARDS] as additional context. Do not allow the model to directly access production network configuration APIs or make routing changes—this prompt is for analysis output that requires human approval before any implementation action.

Human review integration: Route every model output to a review queue where a network architect can approve, reject, or annotate findings. The review interface should display the original topology input alongside the model's analysis, with one-click actions to accept or challenge each finding. Track which findings are accepted versus rejected to build an eval dataset for prompt improvement. For high-risk environments—production connectivity changes, financial networks, healthcare data paths—require explicit human sign-off on all recommendations before any change window opens. The prompt's [RISK_LEVEL] parameter should gate whether the workflow allows automatic low-severity finding acceptance or requires full human review of every output.