Generated banner for GCP To AWS
Generated logo for GCP To AWS

GCP To AWS

ClineOfficialPublished by Cline

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • Low risk

From the author

Migrate workloads from Google Cloud Platform to AWS — including AI and agentic workloads regardless of cloud provider. Triggers on: migrate from GCP, GCP to AWS, move off Google Cloud, migrate Terraform to AWS, migrate Cloud SQL to RDS, migrate GKE to EKS, migrate Cloud Run to Fargate, Google Cloud migration, migrate from OpenAI to Bedrock, move off OpenAI, switch from ChatGPT API to AWS, migrate from Gemini to Bedrock, migrate LangChain to Bedrock, migrate LangGraph to AWS, migrate agentic workloads to AWS, move AI workloads to AWS, migrate my AI app to AWS. Runs a 6-phase process: discover GCP resources from Terraform files, app code, or billing exports, clarify migration requirements, design AWS architecture, estimate costs, generate migration artifacts, and collect optional feedback. Clarify must finish before Design, Estimate, or Generate. Includes AI provider migration guidance (for example, OpenAI to Amazon Bedrock) by selecting closest-fit Bedrock model families for required modality, latency/quality
— the description by Cline

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The gcp-to-aws skill provides a deterministic, multi-phase process to migrate Google Cloud Platform (GCP) workloads to AWS. It supports infrastructure migration via Terraform analysis and AI workload migration by mapping models to Amazon Bedrock. The skill enforces a strict state machine, requiring discovery, clarification, design, estimation, and generation phases to ensure a reliable migration path. It includes specific logic for handling hybrid stacks, AI provider transitions, and complex infrastructure clustering.

What it does

  • Discovers GCP resources from Terraform, application code, or billing data.
  • Clarifies migration requirements through a structured questionnaire.
  • Designs AWS architecture based on GCP workload types and AI model requirements.
  • Estimates costs for the proposed AWS infrastructure and AI services.
  • Generates migration artifacts including Terraform configurations and AI provider adapters.
  • Provides specialized guidance for migrating AI workloads from Gemini or OpenAI to Amazon Bedrock.

When to use it

  • When you need to migrate existing GCP infrastructure to AWS.
  • When you are looking to move AI-driven applications from GCP or OpenAI to Amazon Bedrock.
  • When you have Terraform files or billing exports and need a structured migration plan.
  • When you require a step-by-step, validated approach to re-platforming cloud services.

Advantages

  • Enforces a rigorous, fail-closed state machine to prevent skipped steps.
  • Provides intelligent mapping of GCP services to AWS equivalents.
  • Includes specific logic for AI workload migration and model compatibility.
  • Supports multi-signal discovery using IaC, code, and billing data.
  • Ensures consistent artifact generation through a structured 6-phase process.

Usage examples

“Migrate my GKE and Cloud SQL setup to AWS.”
The agent initiates the discovery phase, analyzing your Terraform files to identify GKE and Cloud SQL resources, then guides you through the clarification and design phases for EKS and RDS.
“I need to move my LangChain app from OpenAI to Bedrock.”
The agent identifies the AI workload, selects the best-fit Bedrock model family, and generates the necessary provider adapters and migration documentation.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/cline/gcp-to-aws/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip gcp-to-aws.zip -d .agents/skills

Documentation by Cline

GCP-to-AWS Migration Skill

Philosophy

  • Re-platform by default: Select AWS services that match GCP workload types (e.g., Cloud Run → Fargate, Cloud SQL → RDS).

  • Dev sizing unless specified: Default to development-tier capacity (e.g., db.t4g.micro, single AZ). Upgrade only on user direction.

  • No human one-time migration costs: Do not present human labor, professional services, or people-time work as dollar estimates or "one-time migration cost" budget categories. Vendor charges grounded in data (for example GCP data transfer egress in the infra estimate when billing exists) are allowed.

  • Multi-signal approach: Design phase adapts based on available inputs — Terraform IaC for infrastructure, billing data for service mapping, and app code for AI workload detection.

  • BigQuery / google_bigquery_*: The skill does not recommend a specific AWS analytics or warehouse service. During Clarify, if discovery shows BigQuery (IaC google_bigquery_* and/or billing rows for BigQuery), you must surface the specialist advisory before Design (see references/phases/clarify/clarify.md). Design output uses Deferred — specialist engagement; keep directing the user to their AWS account team and/or a data analytics migration partner through Design, Estimate, and docs (see references/phases/design/design-infra.md BigQuery specialist gate).


Definitions

  • "Load" = Read the file using the Read tool and follow its instructions. Do not summarize or skip sections.

  • $MIGRATION_DIR = The run-specific directory under .migration/ (e.g., .migration/0226-1430/). Set during Phase 1 (Discover).


Context Loading Rules

Each phase loads reference files on demand. To keep per-turn context manageable and prevent instruction-following degradation:

  • Budget: Each phase should load no more than ~800 lines of instructions (excluding user artifacts like JSON profiles and MCP tool results).

  • Conditional loading: Reference files with trigger conditions (e.g., agentic_profile.is_agentic == true) MUST NOT be loaded unless the condition is met. Do not speculatively load files.

  • No duplication: Model mapping tables, pricing data, and shared warnings exist in one canonical file. Other files reference them; they do not copy them inline.

  • Progressive depth: Phase orchestrators (design.md, generate.md) contain short routing logic that points to detailed sub-files. Load the sub-file only when its path is selected.

Conditional reference files (load ONLY when condition is true):

FileCondition
design-refs/ai-gemini-to-bedrock.mdai-workload-profile.json exists AND summary.ai_source = "gemini" or "both"
design-refs/ai-openai-to-bedrock.mdai-workload-profile.json exists AND summary.ai_source = "openai" or "both"
design-refs/ai-anthropic-to-bedrock.mdai-workload-profile.json exists AND summary.ai_source = "anthropic"
design-refs/ai.mdai-workload-profile.json exists AND summary.ai_source = "other"
design-refs/design-ref-harness.mdagentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "harness"
design-refs/design-ref-agentic-to-agentcore.mdagentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "strands"
shared/retarget-gotchas.mdagentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "retarget"

When adding new reference files, verify the phase's total loaded instructions remain under budget. If a new file would exceed ~800 lines when combined with other loaded refs, split it or make it conditional.

Hybrid stack budget warning:

When both gcp-resource-inventory.json AND ai-workload-profile.json exist, the combined design refs will approach the ~800-line budget. Output this warning to the user before loading the AI design refs:

"⚠️ This is a large hybrid stack (infrastructure + AI workloads). To ensure complete and accurate recommendations, consider running the migration in two separate passes:

Pass 1 — Infrastructure: Run with only your Terraform files to get infra mapping, Terraform generation, and cost estimates.

Pass 2 — AI workloads: Run with only your application code to get Bedrock model recommendations, provider adapters, and AI migration artifacts.

Continue with the combined run? (Y/N)"

If the user chooses to continue, proceed with the combined run. Load AI refs after infra refs to preserve infra instruction fidelity. If the user declines, stop and instruct them to re-run with a single input source type.

This warning is advisory only — it does not block the run.


Prerequisites

User must provide at least one GCP source:

  • Terraform IaC: .tf files (with optional .tfvars, .tfstate)

  • Application code: Source files with GCP SDK or AI framework imports

  • Billing data: GCP billing/cost/usage export files (CSV or JSON)

If none of the above are found, stop and ask user to provide at least one source type.


State Machine

This is the execution controller. After completing each phase, consult this table to determine the next action.

Current StateConditionNext Action
discoverphases.discover != "completed"Load references/phases/discover/discover.md
clarifyphases.discover == "completed" AND phases.clarify != "completed"Load references/phases/clarify/clarify.md
designphases.clarify == "completed" AND phases.design != "completed"Load references/phases/design/design.md
estimatephases.design == "completed" AND phases.estimate != "completed"Load references/phases/estimate/estimate.md
generatephases.estimate == "completed" AND phases.generate != "completed"Load references/phases/generate/generate.md
completephases.generate == "completed" AND phases.feedback == "pending"Set phases.feedback to "completed" (user had two chances), then migration complete
completephases.generate == "completed" AND phases.feedback == "completed"Migration planning complete

How to determine current state (deterministic):

  1. Read $MIGRATION_DIR/.phase-status.json

  2. If current_phase exists, use it (must match one of: discover, clarify, design, estimate, generate, complete)

  3. Otherwise use ordered phase evaluation: discover → clarify → design → estimate → generate

  4. Pick the first phase in that order where phases.<phase> != "completed"; if none, state is complete

Phase gate checks: If prior phase incomplete, do not advance (e.g., cannot enter estimate without completed design).

Clarify is mandatory: Do not load references/phases/design/design.md, references/phases/estimate/estimate.md, or references/phases/generate/generate.md unless $MIGRATION_DIR/.phase-status.json exists and phases.clarify is exactly "completed". A preferences.json file alone is not sufficient proof that Clarify ran. If the user asks to skip Clarify or jump straight to Design, cost estimate, or artifact generation, refuse briefly, then load references/phases/clarify/clarify.md and run Phase 2. There is no exception for "quick" or "obvious" migrations.

Feedback checkpoints: Feedback is not a sequential phase — it is offered at two interleaved checkpoints (after Discover and after Estimate). See the Feedback Checkpoints section below for details.

Handoff Gate Orchestration (Fail Closed)

Load references/shared/handoff-gates.md when executing any phase completion step.

  1. Single $MIGRATION_DIR: Use one run directory for the entire migration. Do not mix artifacts across .migration/*/ sessions.

  2. Re-read from disk: Before each phase (and before each handoff gate), Read required artifacts from $MIGRATION_DIR/. Do not rely on chat memory.

  3. Advance only on HANDOFF_OK: A phase is complete only when its orchestrator emits HANDOFF_OK | phase=<name> | artifacts=.... Do not load the next phase without it.

  4. On GATE_FAIL: Output the failure line(s) to the user in plain language. Do NOT modify artifacts to pass the gate. Do NOT continue to the next phase. Tell the user which phase to re-run.

  5. Re-entry: Re-running an earlier phase after downstream phases completed requires explicit user confirmation; downstream phases must be reset to "pending". See handoff-gates.md re-entry table.

Generate phase additionally loads references/shared/validate-artifacts.md before writing migration-report.html.


State Validation

When reading $MIGRATION_DIR/.phase-status.json, validate before proceeding:

  1. Multiple sessions: If multiple directories exist under .migration/, list them with their phase status and ask: [A] Resume latest, [B] Start fresh, [C] Cancel.

  2. Invalid JSON: If .phase-status.json fails to parse, STOP. Output: "State file corrupted (invalid JSON). Delete the file and restart the current phase."

  3. Unrecognized phase: If phases object contains a phase not in {discover, clarify, design, estimate, generate, feedback}, STOP. Output: "Unrecognized phase: [value]. Valid phases: discover, clarify, design, estimate, generate, feedback."

  4. Unrecognized status: If any phases.* value is not in {pending, in_progress, completed}, STOP. Output: "Unrecognized status: [value]. Valid values: pending, in_progress, completed."

  5. Invalid current_phase (if present): If current_phase is not in {discover, clarify, design, estimate, generate, complete}, STOP. Output: "Unrecognized current_phase: [value]. Valid values: discover, clarify, design, estimate, generate, complete."

  6. Out-of-order completion: For ordered phases [discover, clarify, design, estimate, generate], if any later phase is "completed" while an earlier phase is not "completed", STOP. Output: "Inconsistent phase ordering detected. Reconcile .phase-status.json before resuming."

  7. Multiple active phases: Across core phases {discover, clarify, design, estimate, generate}, at most one phase may be "in_progress". If >1, STOP. Output: "Multiple phases are in_progress. Keep only one active phase before resuming."


State Management

Migration state lives in $MIGRATION_DIR (.migration/[MMDD-HHMM]/), created by Phase 1 and persisted across invocations.

.phase-status.json schema:

{
  "migration_id": "0226-1430",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "in_progress",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

Status values: "pending" → "in_progress" → "completed". Never goes backward. For core phases (discover, clarify, design, estimate, generate), at most one phase may be "in_progress" at any time. current_phase is optional but recommended; when present it is authoritative.

The .migration/ directory is automatically protected by a .gitignore file created in Phase 1.

Phase Status Update Protocol

Use read-merge-write updates for .phase-status.json:

  1. Read the current file before every update.

  2. Change only the phase keys being advanced and last_updated.

  3. Keep prior completed phases unchanged.

  4. Set current_phase to the next deterministic phase (or complete after generate).

  5. Write the full file in the same turn as your final phase work message.

Example — after completing the Clarify phase, write $MIGRATION_DIR/.phase-status.json with:

{
  "migration_id": "MMDD-HHMM",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

Replace MMDD-HHMM with the actual migration ID, generate the last_updated ISO 8601 UTC timestamp yourself, and set each phase to its correct status at that point.


Phase Summary Table

PhaseInputsOutputsReference
Discover.tf files, app source code, and/or billing exports (at least one required)gcp-resource-inventory.json, gcp-resource-clusters.json, ai-workload-profile.json, billing-profile.json, .phase-status.json updated (outputs vary by input)references/phases/discover/discover.md
ClarifyDiscovery artifacts (gcp-resource-inventory.json, gcp-resource-clusters.json, ai-workload-profile.json, billing-profile.json — whichever exist)preferences.json, .phase-status.json updatedreferences/phases/clarify/clarify.md
Designpreferences.json + discovery artifactsaws-design.json (infra), aws-design-ai.json (AI), aws-design-billing.json (billing-only)references/phases/design/design.md
Estimateaws-design.json or aws-design-billing.json or aws-design-ai.json, preferences.jsonestimation-infra.json or estimation-ai.json or estimation-billing.json, .phase-status.json updatedreferences/phases/estimate/estimate.md
Generateestimation-infra.json or estimation-ai.json or estimation-billing.json, aws-design.json or aws-design-billing.json or aws-design-ai.json, preferences.jsongeneration-infra.json or generation-ai.json or generation-billing.json + terraform/, scripts/, ai-migration/, validation-report.json (when infra route active), MIGRATION_GUIDE.md, README.md, .phase-status.json updatedreferences/phases/generate/generate.md
Feedback.phase-status.json (discover completed minimum), all existing migration artifactsfeedback.json, trace.json, .phase-status.json updatedreferences/phases/feedback/feedback.md

MCP Servers

awspricing (for cost estimation):

  • Provides get_pricing, get_pricing_service_codes, get_pricing_service_attributes tools

  • Only needed during Estimate phase. Discover and Design do not require it.

  • Primary pricing source: references/shared/pricing-cache.md (cached 2026 rates, ±5-10% for infrastructure, ±15-25% for AI models). MCP is secondary — used only for services not found in the cache.


Files in This Skill

gcp-to-aws/
├── SKILL.md                                    ← You are here (orchestrator + state machine)
│
├── references/
│   ├── phases/
│   │   ├── discover/
│   │   │   ├── discover.md                     # Phase 1: Discover orchestrator
│   │   │   ├── discover-iac.md                 # Terraform/IaC discovery
│   │   │   ├── discover-app-code.md            # App code discovery
│   │   │   └── discover-billing.md             # Billing data discovery
│   │   ├── clarify/
│   │   │   ├── clarify.md                     # Phase 2: Clarify orchestrator
│   │   │   ├── clarify-global.md              # Category A: Global/Strategic (Q1-Q7)
│   │   │   ├── clarify-compute.md             # Categories B+C: Config Gaps + Compute (Q8-Q11)
│   │   │   ├── clarify-database.md            # Category D: Database (Q12–Q13b)
│   │   │   ├── clarify-ai.md                  # Category F: AI/Bedrock (Q14-Q22)
│   │   │   └── clarify-ai-only.md             # Standalone AI-only migration flow
│   │   ├── design/
│   │   │   ├── design.md                       # Phase 3: Design orchestrator
│   │   │   ├── design-infra.md                 # Infrastructure design (IaC-based)
│   │   │   ├── design-ai.md                    # AI workload design (Bedrock)
│   │   │   └── design-billing.md               # Billing-only design (fallback)
│   │   ├── estimate/
│   │   │   ├── estimate.md                     # Phase 4: Estimate orchestrator
│   │   │   ├── estimate-infra.md               # Infrastructure cost analysis
│   │   │   ├── estimate-ai.md                  # AI workload cost analysis
│   │   │   └── estimate-billing.md             # Billing-only cost analysis
│   │   ├── generate/
│   │   │   ├── generate.md                     # Phase 5: Generate orchestrator
│   │   │   ├── generate-infra.md               # Infrastructure migration plan
│   │   │   ├── generate-ai.md                  # AI migration plan
│   │   │   ├── generate-billing.md             # Billing-only migration plan
│   │   │   ├── generate-artifacts-infra.md     # Terraform configurations
│   │   │   ├── generate-artifacts-scripts.md  # Migration scripts
│   │   │   ├── generate-artifacts-ai.md        # Provider adapter + test harness
│   │   │   ├── generate-artifacts-billing.md   # Skeleton Terraform
│   │   │   └── generate-artifacts-docs.md      # MIGRATION_GUIDE.md + README.md
│   │   └── feedback/
│   │       ├── feedback.md                     # Phase 6: Feedback orchestrator
│   │       └── feedback-trace.md               # Anonymized trace builder
│   │
│   ├── design-refs/
│   │   ├── index.md                            # Lookup table: GCP type → design-ref file
│   │   ├── fast-path.md                        # Deterministic 1:1 mappings (Pass 1)
│   │   ├── compute.md                          # Compute mappings (Cloud Run, GCE, GKE, etc.)
│   │   ├── database.md                         # Database mappings (Cloud SQL, Spanner, etc.)
│   │   ├── storage.md                          # Storage mappings (GCS, Filestore, etc.)
│   │   ├── networking.md                       # Networking mappings (VPC, LB, DNS, etc.)
│   │   ├── messaging.md                        # Messaging mappings (Pub/Sub, etc.)
│   │   └── ai.md                               # AI mappings (Vertex AI → Bedrock)
│   │
│   ├── clustering/terraform/
│   │   ├── classification-rules.md             # Primary/secondary classification
│   │   ├── clustering-algorithm.md             # Cluster formation rules
│   │   ├── depth-calculation.md                # Topological depth calculation
│   │   └── typed-edges-strategy.md             # Edge type assignment
│   │
│   └── shared/
│       ├── schema-phase-status.md              # .phase-status.json schema (canonical reference)
│       ├── schema-discover-iac.md              # gcp-resource-inventory + clusters schemas (loaded by discover-iac.md)
│       ├── schema-discover-ai.md               # ai-workload-profile schema (loaded by discover-app-code.md and discover-iac.md Step 7d)
│       ├── schema-discover-billing.md          # billing-profile schema (loaded by discover-billing.md)
│       ├── schema-estimate-infra.md            # estimation-infra.json schema (loaded by estimate-infra.md at write time)
│       ├── handoff-gates.md                    # Fail-closed phase handoff protocol (GATE_FAIL / HANDOFF_OK)
│       ├── validate-artifacts.md               # Pre-report validation (Generate Step 0; read-only)
│       ├── migration-complexity.md             # Complexity tier definitions (small/medium/large) for timeline scaling
│       ├── pricing-cache.md                    # Cached AWS + source provider pricing (±5-25%, primary source)
│       └── bedrock-quotas.md                   # Bedrock TPM/RPM quota awareness, burndown rates, capacity planning
ConditionAction
No GCP sources found (no .tf, no app code, no billing data)Stop. Output: "No GCP sources detected. Provide at least one source type (Terraform files, application code, or billing exports) and try again."
.phase-status.json missing phase gateStop. Output: "Cannot enter Phase X: Phase Y-1 not completed. Start from Phase Y or resume Phase Y-1."
awspricing unavailable after 3 attemptsDisplay user warning about ±5-25% accuracy. Use pricing-cache.md. Add pricing_source: "cached_fallback" to the applicable estimation-*.json file.
User skips questions or says "use defaults for the rest"Apply documented defaults for remaining questions in the current batch and all subsequent batches. Phase 2 completes either way.
aws-design.json missing required clustersStop Phase 4. Output: "Re-run Phase 3 to generate missing cluster designs."

Defaults

  • IaC output: Terraform configurations, migration scripts, AI migration code, and documentation

  • Region: us-east-1 (unless user specifies, or GCP region → AWS region mapping suggests otherwise)

  • Sizing: Development tier (e.g., db.t4g.micro for databases, 0.5 CPU for Fargate)

  • Migration mode: Adapts based on available inputs (infrastructure, AI, or billing-only)

  • Cost currency: USD

  • Timeline assumption: 2-16 weeks depending on migration complexity — small (2-6 weeks), medium (6-12 weeks), large (12-18 weeks). See references/shared/migration-complexity.md for tier definitions.

Workflow Execution

When invoked, the agent MUST follow this exact sequence:

  1. Load phase status: Read .phase-status.json from .migration/*/.

    • If missing: Initialize for Phase 1 (Discover)

    • If exists: Determine current phase using deterministic rules in State Machine

  2. Determine phase to execute:

    • If current_phase exists: execute that phase.

    • Otherwise execute the first non-completed phase in ordered list: discover → clarify → design → estimate → generate.

    • If all ordered phases are completed: migration is complete (with feedback finalization rule).

  3. Read phase reference: Load the full reference file for the target phase.

  4. Execute ALL steps in order: Follow every numbered step in the reference file. Do not skip, optimize, or deviate.

  5. Validate outputs: Confirm all required output files exist with correct schema before proceeding. Phase orchestrators run Completion Handoff Gate checks per shared/handoff-gates.md.

  6. Handoff gate: Emit HANDOFF_OK or GATE_FAIL per shared/handoff-gates.md. On GATE_FAIL, stop — do not update phase status or load the next phase.

  7. Update phase status: Only after HANDOFF_OK. Use the Phase Status Update Protocol (read-merge-write) in the same turn as the phase's final output message.

  8. Feedback checkpoint: After a phase completes, check if feedback is due (see rules below). This runs before advancing to the next phase.

    • After Discover (if phases.feedback is "pending"): Output to user: "Would you like to share quick feedback (5 optional questions + anonymized usage data) to help improve this tool? Your data never includes resource names, file paths, or account IDs. [A] Send feedback now [B] Wait until after the Estimate phase"

      • If user picks A → Load references/phases/feedback/feedback.md, execute it, then continue to Clarify.

      • If user picks B → Continue to Clarify (feedback stays "pending").

    • After Estimate (if phases.feedback is "pending"): Output to user: "Would you like to share quick feedback now? (5 optional questions + anonymized usage data) [A] Yes, share feedback [B] No thanks, continue to Generate"

      • If user picks A → Load references/phases/feedback/feedback.md, execute it, then continue to Generate.

      • If user picks B → Use the Phase Status Update Protocol to set phases.feedback to "completed". Continue to Generate.

    • After Generate: No feedback offer. If phases.feedback is still "pending", use the Phase Status Update Protocol to set it to "completed" (user had two chances and chose to defer/skip).

  9. Display summary: Show user what was accomplished, highlight next phase, or confirm migration completion.

Critical constraint: Agent must strictly adhere to the reference file's workflow. If unable to complete a step, stop and report the exact step that failed.

User can invoke the skill again to resume from current_phase (or deterministic ordered evaluation when current_phase is absent).

Scope Notes

v1.0 includes:

  • Terraform infrastructure discovery

  • App code scanning (AI workload detection)

  • Billing data import from GCP

  • User requirement clarification (adaptive questions by category)

  • Multi-path Design (infrastructure, AI workloads, billing-only fallback)

  • AWS cost estimation (from pricing API or fallback)

  • Migration artifact generation (Terraform, scripts, AI adapters, documentation)

  • Optional feedback collection with anonymized telemetry

Files

references/phases/clarify/clarify-ai.md

Category F — AI/Bedrock (If ai-workload-profile.json Exists)

Fire when: ai-workload-profile.json exists in $MIGRATION_DIR/.


AI Context Summary

Before presenting questions, show:

AI Context Summary: AI source: [from summary.ai_source: "Gemini", "OpenAI", "Both", or "Other"] Profile origin: [from metadata.profile_source: if iac_vertex or summary.inferred_from_iac is true, state that Terraform was the primary signal and application code did not fully characterize the workload] Models detected: [from models[].model_id; if empty, say None inferred from code or IaC — the following questions will pin down models and frameworks] Capabilities in use: [from integration.capabilities_summary where true; if all false or pattern is unknown, say Not inferred — confirm below] Integration pattern: [from integration.pattern; if unknown, say Unknown (IaC-only)] via [from integration.primary_sdk, or not determined] Gateway/router: [from integration.gateway_type, or "None (direct SDK)"] Frameworks: [from integration.frameworks, or "None"]


Q14 — Framework auto-detection signals

Auto-detect signals — scan IaC and application code before asking:


Multi-Workload Confirmation Table (if workloads[] has ≥ 2 entries)

Fire when: ai-workload-profile.json contains a non-empty workloads[] array with 2 or more entries. This replaces the per-workload Q16–Q22 loop with a single confirmation table.

Before presenting Q16–Q22, show the detected workloads and proposed Bedrock targets:

Detected AI Workloads:

#ModelSDK MethodCapabilityConfidenceProposed Bedrock Target
1gemini-2.5-flashgenerateContenttext_generationmedium[text-class per Q16 priority]
2gemini-2.5-flashgenerateContent (structured)structured_outputhigh[same text-class as row 1]
3imagen-3.0-generate-001generateImagesimage_generationhigh[image-class model]

For each row, you can:

  • Accept — keep the proposed mapping

  • Edit — change the capability or Bedrock target

  • Drop — this isn't an AI workload (false positive)

(v1: merge and split actions are planned for v2)

Do you accept all mappings? Or type the row number to edit.

Timing: This table fires AFTER existing global/infra questions complete (Q1–Q15 and Q14–Q15 AI globals). It does not replace or conflict with the master Clarify orchestrator or PR #57 auto-extraction — those run first, and their answers feed into the capability confirmation.

Behavior:

  1. High-confidence rows (confidence = high): Pre-fill Bedrock target from capability → Bedrock model mapping. Do NOT ask Q16–Q22 for these rows unless the user edits.

  2. Medium/low-confidence rows: Ask at most 2 questions per row:

    • "Is the detected capability correct?" (confirm or select from: text_generation, structured_output, image_generation, embedding, speech_to_text, text_to_speech, unknown)

    • "What matters most for this workload?" (Q16 priority: quality/speed/cost/balanced)

  3. Target mapping (default, overridden by user edits — look up actual model IDs from design-refs tables, not hardcoded names):

    CapabilityTarget ClassNotes
    text_generationText/reasoning classApply Q16–Q19 override hierarchy
    structured_outputText/reasoning class (same as text_generation)Uses same Bedrock target as text_generation for that workload's priority tier — structured output is a mode, not a different model
    image_generationImage generation classe.g., Nova Canvas
    embeddingEmbedding classe.g., Titan Embed Text v2
    speech_to_textSpeech-to-text classe.g., Transcribe
    text_to_speechText-to-speech classe.g., Polly
    unknownAsk Q16–Q22 for this workloadFalls back to full questionnaire
  4. After confirmation — persist workloads[] to preferences.json (REQUIRED):

    Immediately after the user confirms (accepts all, or finishes editing individual rows), write the final workloads[] array to preferences.json. This is the single source of truth for all downstream phases (Design, Estimate, Generate). Do NOT rely on ai-workload-profile.json downstream — it contains the raw Discover output before user edits/drops.

    Write rules:

    • Read existing preferences.json (preserving all non-AI fields written by earlier Clarify categories)

    • Add or overwrite the top-level workloads key with the confirmed array

    • Each entry MUST include: workload_id, model_id, sdk_method, capability, capability_confidence, structured_output, call_sites, target_bedrock_model, and the user's priority/latency_tier selections (use defaults "balanced"/"standard" for high-confidence rows that were auto-accepted)

    • Dropped rows are excluded from workloads[] — they do not appear

    • Write the file atomically (write to .tmp, then rename) to prevent partial writes on failure

    • If write fails: STOP. Output: "Failed to persist workloads to preferences.json — do not proceed to Design."

    Single-workload case: If only 1 workload exists (confirmation table skipped), persist it to workloads[] after Q16–Q22 completes, using the same schema. Design always reads workloads[] regardless of count.

    Zero-workload case: If no AI workloads detected and user doesn't report any, write "workloads": [] to preferences.json. Design emits empty design_blocks[] for this case.

  5. Question budget: 4 global questions (Q14, Q15, framework, spend) + at most 2 per medium/low workload. For an app with 3 high-confidence workloads: 4 questions total, 0 per-workload. For an app with 2 high + 1 medium: 4 + 2 = 6 questions max.

Single-workload fallback: If workloads[] has exactly 1 entry or is empty, skip the confirmation table and proceed with the existing Q16–Q22 flow below.

Known limitations (v1):

  • Gateway calls (LiteLLM, OpenRouter) and custom HTTP calls to AI endpoints are not yet detected as separate workloads — they may be miscategorized or missed. Planned for v2.

  • Merge and split actions are not supported in v1. Users who need to combine or split workloads should edit individual rows.


Q14 — What AI framework or orchestration layer are you using? (select all that apply)

Auto-detect signals — scan IaC and application code before asking:

  • No AI framework imports, raw HTTP calls to OpenAI/Gemini endpoints → A

  • LiteLLM imports or config files → B

  • OpenRouter base URL in code/config → B

  • PortKey, Helicone, Martian SDK imports → B

  • Kong AI Gateway, Apigee AI config files → B

  • Custom proxy class wrapping the AI client → B

  • LangChain/LangGraph imports → C

  • LangChain/LlamaIndex with provider-agnostic model config → C

  • CrewAI imports, Crew and Agent class definitions → D

  • AutoGen imports, ConversableAgent patterns → D

  • Custom multi-agent loop with dispatcher logic → D

  • OpenAI Agents SDK / Swarm imports → E

  • Custom while-loop agent with tool-call parsing → E

  • mcp.server / mcp.client imports, MCP config JSON files → F

  • A2A protocol config or SDK imports → F

  • Vapi, Bland.ai, Retell SDK imports → G

  • Nova Sonic / Nova 2 Sonic or Whisper integration in code → G

Skip when: Auto-detection fully resolves the framework(s). Use detected value(s) with chosen_by: "extracted".

How your AI calls reach the model determines migration effort. Gateway users can often migrate by changing a single config line.

A) No framework — direct API calls to OpenAI/Gemini B) LLM router/gateway (LiteLLM, OpenRouter, PortKey, Kong, Apigee) C) LangChain / LangGraph D) Multi-agent framework (CrewAI, AutoGen, custom) E) OpenAI Agents SDK / custom agent loop F) MCP servers or A2A protocol G) Voice/conversational agent platform (Vapi, Retell, Bland.ai)

(Multiple selections allowed)

AnswerRecommendation ImpactMigration EffortTimeline
A) No framework — direct API callsSwap SDK calls to Bedrock SDK; evaluate Bedrock Agents if planning agenticLow1–3 weeks depending on call sites
B) LLM router/gatewayAdd Bedrock as provider in gateway config; no app code changes; verify SigV4 authMinimalHours to 1–3 days
C) LangChain / LangGraphProvider swap via ChatBedrock; chains/graphs/tools preserved; validate tool schemasLow1–3 days; 1 week if complex graphs
D) Multi-agent frameworkPath 1: Keep framework, swap LLM provider (lower effort). Path 2: Migrate to Bedrock multi-agent (deeper)MediumPath 1: 3–5 days; Path 2: 2–4 weeks
E) OpenAI Agents SDKHighest effort; tightly coupled to OpenAI API; recommend Bedrock Agents or LangGraph as portable stepHigh2–4 weeks
F) MCP / A2ABedrock Agents supports MCP natively; A2A interop available; recommend Bedrock Agents as orchestrationLow–Medium3–5 days MCP; 1–2 weeks A2A
G) Voice platformIf platform supports Bedrock natively → config change; otherwise evaluate Nova 2 SonicMinimal to MediumHours if native; 2–3 weeks if Nova 2 Sonic migration
Combination Logic
CombinationApproach
A onlySimplest path — direct SDK migration
B onlyQuick win — gateway config change, skip SDK migration steps
B + any otherGateway swap is the quick win; assess framework migration as separate workstream
C + ATwo workstreams: LangChain provider swap (fast) + direct call migration (slower)
D + FComplex — multi-agent with MCP tooling; recommend Bedrock Agents to unify orchestration and tools
E + anythingE is the long pole; plan timeline around Agents SDK migration; other layers may be quick wins
Multiple frameworks (C+D, C+E, etc.)Assess independently; prioritize by traffic volume or business criticality; consolidate post-migration

If answer includes B and no other selections, skip or abbreviate SDK migration steps. If answer is A only, proceed with standard model migration flow.

Interpret → ai_framework array (multiple selections → array of all selected values). Default: auto-detect from code, fallback ["direct"].


Q15 — Approximately how much are you spending on OpenAI or Gemini per month?

A) < $500/month B) $500–$2,000/month C) $2,000–$10,000/month D) > $10,000/month E) I don't know

AnswerRecommendation Impact
< $500/monthAWS Activate Founders (up to $5,000 credits, self-service, no VC needed — apply at aws.amazon.com/startups/credits); Bedrock free tier covers initial testing; Bedrock cost comparison shows modest savings
$500–$2,000/monthAWS Activate Portfolio (up to $200,000 credits for VC/accelerator-backed startups — requires Activate Provider Org ID); Bedrock cost comparison highlighted; credits apply to Bedrock third-party models including Claude
$2,000–$10,000/monthAWS Activate Portfolio (up to $200,000); Bedrock cost savings prominently featured; Savings Plans analysis; if agentic workload detected → flag AWS Generative AI Accelerator (up to $1M credits, cohort-based, adjacent to the credits-hub funnel)
> $10,000/monthAWS Credits for AI Startups ($200,000+, invite-only for startups ready to scale post-Activate-Portfolio — contact your AWS Account Manager; see aws.amazon.com/startups/credits); dedicated AI migration support; Bedrock provisioned throughput analysis; if agentic workload detected → also flag AWS Generative AI Accelerator (up to $1M credits, 8-week cohort — aws.amazon.com/startups/generative-ai/accelerator)

Activate eligibility (Founders & Portfolio): Pre-Series B, founded in the last 10 years, AWS Account on Paid Tier Plan, and either new to Activate Credits or requesting more credits than previously received.

Interpret → ai_monthly_spend. Default: B → "$500-$2K".


Q16 — What matters most for your AI workloads?

Present with concrete anchors: Quality = legal analysis/code gen; Speed = autocomplete/live chat; Cost = classification/tagging at scale; Specialized = specific feature (→ Q17); Balanced = all-rounder.

A) Best quality/reasoning — accuracy matters most, willing to pay more B) Fastest speed — response time is the primary constraint C) Lowest cost — high volume, budget tight, good-enough quality at scale D) Specialized capability — rely on a specific feature (covered in Q17) E) Balanced — no single dimension dominates F) I don't know

AnswerRecommendation Impact
Best quality/reasoningClaude Sonnet 4.6 (latest, highest reasoning in Sonnet family) — primary; Claude Opus 4.7 for the most demanding reasoning tasks (same headline on-demand $5/$25 as Opus 4.6 on standard Bedrock pricing); Claude Opus 4.6 remains a valid alternative
Fastest speedClaude Haiku 4.5 — lowest latency in Claude family; also consider Amazon Nova Micro/Lite for cost-optimized speed
Lowest costClaude Haiku 4.5 or Amazon Nova Micro — lowest cost per token
Specialized capabilityDeferred to Q17 to determine which model
BalancedClaude Sonnet 4.6 as default balanced recommendation

Interpret → ai_priority. Default: E → "balanced".


Q17 — What is your MOST CRITICAL specialized AI feature?

A) Function calling / Tool use B) Ultra-long context (> 300K tokens) C) Extended thinking / Chain-of-thought D) Prompt caching E) RAG optimization F) Agentic workflows G) Real-time speed (< 500ms) H) Multimodal with image generation I) Real-time conversational speech J) None — standard features are sufficient

AnswerRecommendation Impact
Function calling / Tool useClaude Sonnet 4.6 — best-in-class tool use on Bedrock via structured JSON tool schemas; supports parallel tool calls and multi-turn tool use
Ultra-long context (> 300K tokens)Claude Sonnet/Opus 4.6 long-context SKUs where available (standard on-demand for 4.6 matches base tier in US East N. Virginia per Amazon Bedrock pricing); or Llama 4 Scout (10M), Llama 4 Maverick (1M), Nova 2 Pro/Lite (1M) for very large native context windows
Extended thinking / Chain-of-thoughtClaude Sonnet 4.6 with extended thinking mode; Claude Opus 4.6 for most complex reasoning
Prompt cachingClaude Sonnet 4.6 with prompt caching enabled; cost savings analysis included. Caveat: caching only helps for long, repeated context (system prompts, documents). Per-model minimum token thresholds (~1K–4K tokens) and TTL apply — short prompts won't cache. Verify current minimums at docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html before recommending.
RAG optimizationAmazon Bedrock Knowledge Bases recommended alongside model; Titan Embeddings for vector store
Agentic workflowsClaude Sonnet 4.6 with Bedrock Agents; multi-agent orchestration guidance included
Real-time speed (< 500ms)Claude Haiku 4.5 or Nova Micro; streaming response guidance included
Multimodal with image generationClaude Sonnet 4.6 (vision) + Amazon Nova Canvas for generation
Real-time conversational speechAmazon Nova 2 Sonic recommended for speech-to-speech; latency guidance included
NoneDefault recommendation from Q16 priority stands

Interpret → ai_critical_feature. Default: J → no override.


Q18 — What's your AI usage volume and cost tolerance?

A) Low volume + quality priority — small-scale, quality matters most B) Medium volume + balanced — moderate production use, balanced approach C) High volume + cost critical — high scale, budget is tight, need cost control

AnswerRecommendation Impact
Low volume + quality priorityOn-demand Claude Sonnet; no provisioned throughput needed
Medium volume + balancedOn-demand Claude Sonnet or Haiku depending on Q16; Savings Plans analysis
High volume + cost criticalProvisioned throughput strongly recommended; Claude Haiku or Nova Micro; prompt caching analysis included

Interpret → ai_token_volume: A → "low", B → "medium", C → "high". Default: A → "low".


Q19 — Which Gemini or OpenAI model are you currently using?

Auto-detect signal: If ai-workload-profile.json exists and models[0].model_id is set with detection confidence ≥ 0.8, map to the matching Q19 answer and skip Q19. Set ai_model_baseline with chosen_by: "extracted". If multiple models detected with similar confidence, ask Q19.

Skip when: Primary model fully resolved from discovery. Use detected value with chosen_by: "extracted".

Establishes baseline Bedrock recommendation. Override hierarchy: Q17 special features (hard override) > Q16 priority > Q18/Q21 volume and latency > Q19 source model (baseline only).

A) Gemini 3.5 Flash (GA — current flagship Flash model) B) Gemini 3.5 Flash Thinking (thinking budget enabled) C) Gemini 3.1 Pro D) Gemini 3.1 Flash-Lite (high-volume, low-cost) E) Gemini 2.5 Flash (standard, no thinking budget) F) Gemini 2.5 Flash Thinking (thinking budget enabled — variable output pricing) G) Gemini 2.5 Pro H) Gemini 3 Pro / 3.1 Pro Preview I) Gemini Flash (2.0 Flash) or Gemini Flash 1.5 (EOL Sep 2025 — flag for source model upgrade) J) Gemini Pro 1.5 (EOL Sep 2025 — flag for source model upgrade) K) GPT-3.5 Turbo L) GPT-4 / GPT-4 Turbo M) GPT-4o N) GPT-5.4 / GPT-5.4 Mini / GPT-5.4 Nano O) GPT-5 / GPT-5.x (older) P) GPT-5.5 / GPT-5.5 Pro Q) o-series (o1, o3) R) Other / Multiple models S) I don't know

Source ModelBaseline Bedrock RecommendationPricing Context
Gemini 3.5 Flash (GA)Nova Lite ($0.06/$0.24) — 94% cheaperGemini 3.5 Flash is $1.50/$9.00 — 5x more expensive than old 2.5 Flash; Nova Lite is the cost-equivalent; very strong migration case
Gemini 3.5 Flash ThinkingClaude Sonnet 4.6 with extended thinking ($3/$15)At $1.50/$9.00 base + thinking tokens, Sonnet 4.6 is comparable or cheaper at full thinking; profile actual thinking usage before committing
Gemini 3.1 Flash-LiteNova Micro ($0.035/$0.14) — 88% cheaper; or Nova Lite ($0.06/$0.24) — 76% cheaperGemini 3.1 Flash-Lite is $0.25/$1.50; strong Bedrock cost case
Gemini 2.5 Flash (standard)Nova Lite ($0.06/$0.24) — 88% cheaperGemini 2.5 Flash is $0.30/$2.50; Nova Lite is the cost-equivalent; strong migration case
Gemini 2.5 Flash ThinkingClaude Sonnet 4.6 with extended thinking ($3/$15)Thinking output pricing on Gemini 2.5 Flash ranges $0.60–$3.50/M depending on thinking budget; at full thinking budget Sonnet 4.6 is comparable or cheaper; flag that thinking token costs vary and user should profile their actual thinking budget usage before committing
Gemini 2.5 ProNova 2 Pro ($1.38/$11) — 9% cheaper; or Nova Pro ($0.80/$3.20) — 62% cheaperGemini 2.5 Pro is $1.25/$10; migration case is cost + AWS consolidation
Gemini 3 Pro / 3.1 ProClaude Sonnet 4.6 ($3/$15) — agentic reliability; or Nova 2 Pro ($1.38/$11) — costGemini 3.1 Pro is $2/$12 — cheaper than Sonnet 4.6; migration case is agentic reliability and AWS ecosystem, NOT cost. Be honest: Gemini 3.1 Pro leads on general benchmarks.
Gemini Flash 1.5 / 2.0 (older)Nova Lite ($0.06/$0.24) or Nova Micro ($0.035/$0.14) — flag Gemini 1.5 Flash as EOL (Sep 2025); recommend upgrading source model to 3.5 Flash before or alongside migrationStrong Bedrock cost savings; 1.5 Flash is past EOL so migration is doubly urgent
Gemini Pro 1.5 (older)Claude Sonnet 4.6 ($3/$15) — flag Gemini 1.5 Pro as EOL (Sep 2025); recommend upgrading source model to 3.1 Pro before or alongside migration1.5 Pro is past EOL; migration to Bedrock and source model upgrade should be planned together
GPT-3.5 TurboClaude Haiku 4.5 ($1/$5) — cost-equivalentHaiku is faster and cheaper
GPT-4 / GPT-4 TurboClaude Sonnet 4.6 ($3/$15) — quality equivalentMajor savings: GPT-4 Turbo is $10/$30 vs Sonnet $3/$15
GPT-4oClaude Sonnet 4.6 ($3/$15) — performance equivalentModest savings on output; input slightly higher on Bedrock
GPT-5.4Claude Sonnet 4.6 ($3/$15) — near price parityGPT-5.4 is $2.50/$15 — ~5% cheaper; migration case is AWS consolidation, not cost
GPT-5.4 MiniNova Lite ($0.06/$0.24) — massive cost savings94% cheaper on Bedrock; strong migration case
GPT-5.4 NanoNova Micro ($0.035/$0.14) — massive cost savings87% cheaper on Bedrock; strong migration case
GPT-5.4 ProNova 2 Pro ($1.38/$11) — flagship reasoning on AWS94% cheaper on Bedrock; strongest migration case
GPT-5 / GPT-5.x (older)Claude Sonnet 4.6 ($3/$15) — performance equivalentGPT-5 is $1.25/$10 — savings story is quality/features, not cost
GPT-5 (flagship use case)Claude Opus 4.6 ($5/$25) — flagship-to-flagshipOpus still cheaper than GPT-5 Pro ($15/$120)
GPT-5.5Claude Opus 4.6 ($5/$25) — flagship-to-flagshipBedrock 17% cheaper on output ($25 vs $30); same input price
GPT-5.5 (cost-sensitive)Claude Sonnet 4.6 ($3/$15) — 53% cheaperStrong cost case; Sonnet leads on agentic reliability
GPT-5.5 ProNova 2 Pro ($1.38/$11) — flagship reasoning on AWS95% cheaper on Bedrock; strongest migration case
o-series (o1, o3)Claude Sonnet 4.6 with extended thinking; Opus 4.6 for most demandingo1 is $15/$60 — significant savings with Sonnet 4.6 at $3/$15

Override examples: GPT-4 + Q16=cost → Haiku; Flash + Q17=extended thinking → Sonnet; GPT-4o + Q17=speech → Nova 2 Sonic; GPT-3.5 + Q22=complex → Sonnet; GPT-5 + Q16=balanced → Sonnet; GPT-5.5 + Q16=cost → Sonnet 4.6; Gemini 2.5 Flash Thinking + Q16=cost → Nova Lite (if thinking budget is low) or Sonnet 4.6 (if full thinking mode).

Interpret → ai_model_baseline. Default: auto-detect from code, fallback Q16 priority-based.


Q20 — What input types must the model accept: text only, images (vision), or audio/video?

Auto-detect signal: Read integration.capabilities_summary:

SignalExtractSkip Q20?
vision: trueai_vision: "vision-required"Yes — chosen_by: "extracted"
speech_to_text: true or text_to_speech: trueai_vision: "audio-video"Yes
all false / text onlyai_vision: "text-only"Yes
image_generation: true and vision: falsenote in ai_capabilities_required; skip Q20 (image output ≠ vision input)Yes

Skip when: Modalities fully resolved from capabilities_summary. Use detected value with chosen_by: "extracted".

A) Text only B) Vision required — model must process images C) Audio/Video inputs needed

AnswerRecommendation Impact
Text onlyFull model catalog available; cheapest/fastest text model per Q16 priority
Vision requiredClaude Sonnet or Haiku (both support multimodal vision); Nova Micro excluded (text-only)
Audio/Video inputsAmazon Nova 2 Sonic (audio); Nova Reel v1 for video (Legacy — EOL Sep 30, 2026); Claude excluded for audio/video input

Interpret → ai_vision. Default: A → no constraint.


Q21 — How important is AI response speed?

Present with concrete anchors: Critical = autocomplete/live chat/real-time transcription; Important = chat assistant/search augmentation; Flexible = report generation/batch analysis.

A) Critical (< 500ms) — users staring at a loading spinner B) Important (< 2s) — quick response expected, brief pause acceptable C) Flexible (2–10s) — users can wait, background/async acceptable

AnswerRecommendation Impact
Critical (< 500ms)Claude Haiku 4.5 or Nova Micro; streaming required; provisioned throughput for consistent latency
Important (< 2s)Claude Sonnet 4.6 with streaming; standard on-demand acceptable
Flexible (2–10s)Any model; batch inference considered for cost savings at high volume

Interpret → ai_latency. Default: B → "important".


Q22 — How complex are your AI tasks?

Present with concrete examples: Simple = classify/extract/summarize; Moderate = analyze+JSON/few-shot; Complex = multi-turn reasoning/tool use/agentic.

A) Simple (classification, short summaries, extraction) B) Moderate (analysis, structured content, few-shot) C) Complex (multi-step reasoning, tool use, agentic workflows)

AnswerRecommendation Impact
SimpleClaude Haiku 4.5 or Nova Micro sufficient; significant cost savings vs larger models
ModerateClaude Sonnet 4.6 recommended; Haiku may suffice with prompt engineering
ComplexClaude Sonnet 4.6 required; extended thinking considered; Claude Opus 4.7 / 4.6 for hardest tasks

Interpret → ai_complexity. Default: B → "moderate".


Category G — Agentic Workflows (If agentic_profile exists in ai-workload-profile.json)

Fire when: ai-workload-profile.json contains agentic_profile with is_agentic: true.

Skip entirely when: agentic_profile is absent from ai-workload-profile.json.


Agentic Context Summary

Before presenting Category G questions, show:

Agentic Context Summary: Framework: [from agentic_profile.framework] Agents detected: [from agentic_profile.agent_count] ([list agents[].agent_id]) Orchestration pattern: [from agentic_profile.orchestration_pattern] Tools: [from agentic_profile.tool_count] tools detected Memory: [from agentic_profile.has_memory; if true, backend: agentic_profile.memory_backend] Human-in-the-loop: [from agentic_profile.has_human_in_loop]


Q23 — How do you want to migrate your agent system?

Auto-detect signals — recommend default based on agentic_profile.framework:

  • gateway_type is "llm_router" (LiteLLM or OpenRouter detected) → Default to A (retarget). These users are already abstracted from the model provider — migration is a config change (swap model IDs), not a code rewrite. Set migration_approach: "retarget" automatically and skip Q23 unless the user explicitly asks to evaluate Harness or Strands.

  • langgraph, crewai, autogen → Default to A (retarget). These frameworks support Bedrock as a model provider with minimal code changes.

  • openai_agents → Surface all options. OpenAI Agents SDK is tightly coupled to OpenAI API; retarget is harder. Note partial retarget (HTTP-compatible routing to Bedrock) as a bridge.

  • strands → Already AWS-native. Recommend B (Harness) for managed deployment or note "already on target framework."

  • custom → Surface all options. Custom loops vary widely in complexity.

Skip when: Auto-detection fully resolves AND user has no preference signal. Use detected default with chosen_by: "extracted".

Your agent system can migrate to AWS in different ways, each with different effort and risk:

A) Retarget — Keep your current framework ([framework name]), swap the model layer to Bedrock. Fastest path, lowest risk. Your orchestration code stays the same. B) AgentCore Harness — Declare your agent as configuration (model + tools + prompt). Get managed runtime, memory, identity, and observability. Good for simpler agents or incremental migration. (Preview — 4 regions: us-east-1, us-west-2, eu-central-1, ap-southeast-2) C) Strands native — Rewrite orchestration using AWS Strands SDK on AgentCore. Most AWS-integrated, highest effort. Best for teams wanting full AWS-native multi-agent capabilities. D) I'm not sure — Help me decide based on my workload.

AnswerWhen it fitsEffort rangeRisk
A) RetargetWorking system, team knows the framework, need to ship fast. LangGraph/CrewAI/AutoGen with Bedrock model provider support.1–3 weeks depending on agent count, tool count, test coverageLow — orchestration unchanged
B) AgentCore HarnessSimple single-agent, OpenAI Assistants migration, want managed runtime, or incremental migration (run existing models on AWS infra first).3–10 days depending on tool complexity and memory requirementsLow — config-based, reversible
C) Strands nativeOpenAI Agents SDK or custom loops where retarget doesn't work well, multi-agent systems, team willing to refactor for AWS-native benefits.2–6 weeks depending on agent count, graph complexity, tool countMedium — orchestration rewrite
D) Undecided———

For OpenAI Agents SDK users: Note that a partial retarget (HTTP-compatible routing to Bedrock while keeping OpenAI SDK orchestration) is a valid short-lived bridge before committing to B or C. This is not a fourth path — it's a Phase 0 step within B or C.

If answer is D: Recommend A (retarget) as default for LangGraph/CrewAI/AutoGen users. Recommend B (Harness) for OpenAI Assistants or simple single-agent patterns. Recommend C (Strands) only if user explicitly wants AWS-native multi-agent and accepts refactor cost.

Interpret → ai_constraints.agentic.migration_approach: A → "retarget", B → "harness", C → "strands", D → "undecided" (treated as "retarget" in Design unless overridden). Default: auto-detect based on framework.


Q24 — Do your agents need to remember context across sessions?

A) No — each request is independent, no memory needed B) Within a session — conversation history during a single interaction, but fresh start each time C) Across sessions — remember user preferences, past interactions, accumulated knowledge between separate conversations

AnswerRecommendation Impact
No memoryStandard stateless invocation. No AgentCore Memory needed.
Within sessionAgentCore Harness sessions are stateful by default (microVM per session). No additional config needed for Harness path. For retarget path: existing framework memory (e.g., LangGraph checkpointer) continues to work.
Across sessionsAgentCore Memory service recommended. Persists knowledge, user preferences, and interaction history across sessions. For retarget path: evaluate existing memory backend migration (Redis → ElastiCache, Postgres → RDS, vector store → OpenSearch Serverless).

Interpret → ai_constraints.agentic.memory_requirement: A → "none", B → "session", C → "cross_session". Default: B → "session".


Q25 — How long do your agent tasks typically run?

A) Quick (< 30 seconds) — simple tool calls, single-turn responses B) Medium (30 seconds – 5 minutes) — multi-step reasoning, several tool calls C) Long (5 minutes – 1 hour) — complex research, multi-agent collaboration, iterative refinement D) Very long (1+ hours) — extended autonomous work, large-scale data processing

AnswerRecommendation Impact
QuickStandard invocation. Any deployment model works.
MediumAgentCore Runtime recommended for managed scaling. Harness sessions handle this natively.
LongAgentCore Runtime strongly recommended (supports up to 8-hour sessions). Serverless alternatives (Lambda) will timeout.
Very longAgentCore Runtime required (8-hour max session). If tasks exceed 8 hours: recommend breaking into sub-tasks with session chaining, or evaluate custom compute (ECS/EKS).

Interpret → ai_constraints.agentic.task_duration: A → "quick", B → "medium", C → "long", D → "very_long". Default: B → "medium".


Q26 — Do you want to migrate incrementally?

A) Yes — run my existing models (OpenAI/Gemini) on AWS infrastructure first, then swap to Bedrock models later when I'm confident B) No — do a full model swap to Bedrock in one go C) I'm not sure

AnswerRecommendation Impact
Yes (incremental)AgentCore Harness multi-model switching: deploy on Harness with existing OpenAI/Gemini model (API key in AgentCore Identity), then override --model-id per invocation to A/B test Bedrock. Swap default when confident. Works for both Harness and retarget paths.
No (full swap)Standard migration: swap model layer directly to Bedrock. Faster to complete but higher risk per deployment.
Not sureDefault to incremental if using Harness path (it's free — multi-model switching is built in). Default to full swap if retarget path with LangChain/LangGraph (simpler to test with framework's built-in model switching).

Interpret → ai_constraints.agentic.incremental_migration: A → true, B → false, C → auto-select based on migration_approach. Default: true for Harness path, false for retarget path.


Category G Combination Logic

CombinationDesign Impact
A (retarget) + C (cross-session memory)Retarget model layer + migrate memory backend to AWS (Redis → ElastiCache, etc.)
B (harness) + A (no memory)Simplest Harness config — model + tools + prompt, no memory setup
B (harness) + C (cross-session memory)Harness + AgentCore Memory service
B (harness) + D (very long tasks)Flag: 8-hour session limit. Recommend task decomposition or session chaining.
C (strands) + C (cross-session memory)Strands SessionManager + AgentCore Memory
Any + A (incremental)Include incremental migration script in Generate artifacts

Category H — Startup Programs (Always fires when Category F fires)

Fire when: ai-workload-profile.json exists (same trigger as Category F). Ask once, after Q26 if agentic, or after Q22 if non-agentic.


Q27 — Have you applied for AWS Activate credits?

Rationale: AWS Activate credits apply directly to Bedrock usage (including Claude, Llama, Nova, and other third-party models). Surfacing eligibility at the migration decision moment helps startups reduce the cost of the migration itself. This takes 30 seconds to answer and can unlock $5K–$200K in credits.

Activate eligibility: Pre-Series B, founded in the last 10 years, AWS Account on Paid Tier Plan, and either new to Activate Credits or requesting more credits than previously received.

AWS Activate credits offset Bedrock costs during and after migration — including Claude, Llama, and Nova models. Eligible startups can get $5K–$200K depending on funding stage.

A) Yes — already have AWS Activate credits B) No — haven't applied yet (self-funded or pre-VC) C) No — VC/accelerator-backed but haven't applied D) I don't know

AnswerRecommendation Impact
Already have creditsNote credit balance in migration plan; flag Bedrock usage as credit-eligible
No — self-fundedFlag AWS Activate Founders (up to $5,000, self-service): aws.amazon.com/startups/credits — apply before starting migration to offset Bedrock testing costs
No — VC/accelerator-backedFlag AWS Activate Portfolio (up to $200,000): requires Activate Provider Org ID from your VC/accelerator — contact them for the Org ID before applying
Don't knowSurface both tiers; recommend checking with investors/accelerator for Org ID

If ai_monthly_spend is ">$10K": also flag AWS Credits for AI Startups ($200,000+, invite-only for startups ready to scale post-Activate-Portfolio — contact your AWS Account Manager; aws.amazon.com/startups/credits).

If ai_monthly_spend is "$2K-$10K" or ">$10K" AND agentic_profile.is_agentic == true: also flag AWS Generative AI Accelerator (up to $1M credits, 8-week cohort — adjacent cohort program, distinct from the credits-hub funnel): aws.amazon.com/startups/generative-ai/accelerator

Interpret → startup_program_status: A → "has_credits", B → "eligible_founders", C → "eligible_portfolio", D → "unknown". Default: D → "unknown".


Preferences Output — ai_constraints.agentic

Category G answers are stored in preferences.json → ai_constraints.agentic:

{
  "ai_constraints": {
    "agentic": {
      "migration_approach": "retarget|harness|strands|undecided",
      "memory_requirement": "none|session|cross_session",
      "task_duration": "quick|medium|long|very_long",
      "incremental_migration": true
    }
  }
}

Field contract (consumed by Design phase):

  • migration_approach — Routes Design to the correct path: "retarget" uses existing model-swap flow, "harness" loads design-ref-harness.md, "strands" loads design-ref-agentic-to-agentcore.md

  • memory_requirement — Determines whether AgentCore Memory is included in design

  • task_duration — Determines AgentCore Runtime recommendation and session limit warnings

  • incremental_migration — Determines whether incremental migration artifacts are generated

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Names Claude Code tools, Needs an MCP server

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Cline
Publisher
Cline (Official)
Source
cline/skills · skills/gcp-to-aws · commit 2637846
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Cline or Cline.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download gcp-to-aws.zip