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/generate/generate-artifacts-ai.md

Generate Phase: AI Artifact Generation

Loaded by generate.md when generation-ai.json and aws-design-ai.json exist.

Execute ALL steps in order. Do not skip or optimize.

Overview

Generate migration artifacts from the AI migration plan and design. Artifacts vary by gateway type detected in discovery.

Outputs (all users):

  • ai-migration/setup_bedrock.sh — Bedrock model access and IAM setup

  • ai-migration/test_comparison.py — A/B test harness (always Python)

  • ai-migration/bedrock_monitoring.tf — Bedrock cost budget, anomaly detection, inference profiles (always)

Outputs (direct SDK users — ai_framework = "direct"):

  • ai-migration/provider_adapter.{py,js,go} — Provider abstraction with feature flag

Outputs (gateway users — ai_framework != "direct"):

  • ai-migration/gateway_config.{yaml,py,json} — Gateway-specific configuration snippet

Outputs (if user opted into model evaluation in generate-ai.md Part 0):

  • ai-migration/eval-prompts.jsonl — Evaluation prompt dataset

  • ai-migration/run-evaluation.sh — Bedrock evaluation job script

Prerequisites

Read from $MIGRATION_DIR/:

  • aws-design-ai.json (REQUIRED) — AI architecture with model mappings and code migration plan

  • generation-ai.json (REQUIRED) — AI migration plan with timeline and rollback strategy

  • ai-workload-profile.json (REQUIRED) — AI workload profile with models, languages, and capabilities

If any required file is missing: STOP. Output: "Missing required artifact: [filename]. Complete the prior phase that produces it."

Sparse / IaC-only profile: If ai-workload-profile.json has empty models[] or metadata.profile_source is iac_vertex, use aws-design-ai.json for Bedrock targets and example prompts; do not fail solely because discovery did not list model IDs.


Step 0: Determine Artifact Path

Check preferences.json → ai_constraints.ai_framework.value and aws-design-ai.json → ai_architecture.code_migration.migration_path:

  • migration_path = "mantle" → Generate Mantle setup (Step 1M) + setup (Step 3) + test harness (Step 2). Skip provider adapter (Step 1).

  • migration_path = "gpt-oss" → Generate provider adapter (Step 1) targeting the gpt-oss model on Bedrock via the Converse API + setup (Step 3) + test harness (Step 2). Use the Bedrock model ID from aws-design-ai.json → ai_architecture.bedrock_models[].aws_model_id (the gpt-oss model ID). Do NOT generate a Mantle script — gpt-oss uses the Converse API directly.

  • "direct" or absent → Generate provider adapter (Step 1) + setup (Step 3) + test harness (Step 2)

  • "llm_router", "api_gateway", "voice_platform", or "framework" → Skip Step 1, generate gateway config (Step 3B) instead

Step 3F runs for ALL paths (direct, mantle, gpt-oss, gateway, harness, strands) — generate bedrock_monitoring.tf regardless of migration path.

Determine language (direct SDK users only): Read ai-workload-profile.json → integration.languages array. Use the first entry: "python" → .py, "javascript"/"typescript" → .js, "go" → .go, other/unknown → .py.


Step 1M: Generate Mantle Migration Script (OpenAI SDK via Mantle)

Generate ai-migration/migrate_to_mantle.sh — a shell script that configures the OpenAI SDK to use Bedrock's Mantle endpoints.

Requirements:

  • Dry-run by default (--execute flag to apply)

  • Print the environment variables to set: OPENAI_BASE_URL=https://bedrock-mantle.{region}.api.aws/v1, OPENAI_API_KEY=<bedrock-api-key>

  • Print the model string change: current model ID → Bedrock model ID from aws-design-ai.json

  • Include a quick verification call using the OpenAI SDK against the Mantle endpoint

  • Add a warning comment about max_tokens: OpenAI SDK users migrating via Mantle carry over their existing max_tokens value unchanged. If the existing value is 4096 (OpenAI default), this reduces Bedrock concurrency by 5–8x on TPM quota. Instruct users to audit max_tokens before production and include the workload-type lookup table (see Step 1M max_tokens guidance above).

  • Note: "No code changes required. Your existing OpenAI SDK calls work unchanged."

  • Reference Mantle documentation for API key generation

  • Set max_tokens default to 1024 in the generated migration script with an explanatory comment. Do NOT inherit the caller's existing max_tokens value (often 4096 from OpenAI defaults) — this reduces concurrency by 5–8x on Bedrock's TPM quota. Include a workload-type lookup table as a comment so users tune before production:

    # max_tokens guidance — tune before production:
    # | Workload type                                | Suggested max_tokens |
    # |--------------------------------------------|----------------------|
    # | Classification / extraction / routing       | 256–512              |
    # | Chat / Q&A / summarization                  | 512–1024 (default)   |
    # | Long-form generation / reports              | 2048–4096             |
    # | Tool outputs / multi-step reasoning         | 2048–8192             |
    # | Code generation                             | 2048–4096             |
    # TODO: Review and adjust max_tokens for your workload before deploying to production.
    MAX_TOKENS=1024 # Starting point — see table above

Skip Step 1 (provider adapter) when this step runs — the OpenAI SDK is the adapter.


Step 1: Generate Provider Adapter (Direct SDK Only)

Generate ai-migration/provider_adapter.{py,js,go} — an abstraction layer that lets the user switch between the source AI provider and Bedrock via an environment variable.

Requirements:

  • Read AI_PROVIDER env var to select provider: vertex_ai (current), bedrock (target), shadow (both — return source response, log Bedrock response)

  • Expose only the methods matching capabilities in ai-workload-profile.json → integration.capabilities_summary:

    • text_generation: true → generate(prompt) → str

    • streaming: true → generate_stream(prompt) → Iterator[str]

    • embeddings: true → embed(text) → list[float]

  • Source provider class: Use SDK imports from ai-workload-profile.json → integration.sdk_imports. Use model IDs from ai-workload-profile.json → models[].model_id.

  • Bedrock provider class: Use boto3 Converse API (converse for generate, converse_stream for streaming, invoke_model for embeddings with Titan). Use inference profile ARNs from bedrock_monitoring.tf output bedrock_inference_profile_arns as modelId — this enables cost attribution in Cost Explorer. Fall back to raw model IDs from aws-design-ai.json → ai_architecture.bedrock_models[].aws_model_id if profiles are not yet deployed. Use region from preferences.json → design_constraints.target_region.

    # Use inference profile ARN for cost attribution (preferred)
    # Set BEDROCK_INFERENCE_PROFILE_ARN from terraform output bedrock_inference_profile_arns
    MODEL_ID = os.environ.get(
        "BEDROCK_INFERENCE_PROFILE_ARN",
        "{aws_model_id}"  # fallback — replace with actual ARN from aws-design-ai.json
    )
  • Shadow mode: Send requests to both providers, return source response, log Bedrock response for comparison.

  • Include error handling and logging for API calls.

For JS: use @aws-sdk/client-bedrock-runtime + @google-cloud/vertexai. For Go: use github.com/aws/aws-sdk-go-v2/service/bedrockruntime + cloud.google.com/go/aiplatform.


Step 2: Generate Test Comparison Harness

Generate ai-migration/test_comparison.py — always Python regardless of adapter language.

Requirements:

  • Accept prompts from a JSON file (--prompts) or use built-in defaults (--quick)

  • Run each prompt against both the source provider and Bedrock

  • Measure per-prompt: latency (ms), success/failure, response text (truncated to 500 chars)

  • Compute summary statistics: p50/p95/mean latency per provider, quality score (trait matching against expected traits), pass/fail criteria

  • Pass criteria: Bedrock latency ≤ 2x source latency, mean quality score ≥ 0.9

  • Output structured JSON to --output (default: comparison_results.json)

  • Built-in test prompts: include 3-5 prompts based on ai-workload-profile.json → models[].usage_context covering the primary use case

  • Import the provider adapter via from provider_adapter import get_provider


Step 3: Generate Bedrock Setup Script

Generate ai-migration/setup_bedrock.sh.

Requirements:

  • Dry-run by default (--execute flag to run for real)

  • Step 1 — Request model access: List each model from aws-design-ai.json → bedrock_models[].aws_model_id and the embedding model

  • Step 2 — Create IAM role: Trust policy for the compute platform (Lambda, ECS, or EC2 based on aws-design.json if present). Bedrock policy: bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream scoped to arn:aws:bedrock:*::foundation-model/*

  • Step 3 — Print required environment variables: AWS_REGION, AI_PROVIDER=bedrock, model IDs

  • Step 4 — Check quota: Query current TPM quota for the primary model via aws service-quotas get-service-quota. If aws-design-ai.json → ai_architecture.quota_risk is "high" or "medium", print warning: "⚠️ Your token volume may exceed default Bedrock quotas. Request a quota increase via Service Quotas console (allow 1–5 business days)." Include the aws service-quotas request-service-quota-increase command template.

  • Step 5 — Verification: Test Bedrock access with a simple converse call using the primary model

  • If $MIGRATION_DIR/terraform/ exists, print coordination note: "Ensure the IAM role is referenced in compute.tf task definitions"

  • Use region from preferences.json → design_constraints.target_region


Step 3B: Generate Gateway Configuration (Gateway Users Only)

Skip if ai_framework = "direct" or absent. Read preferences.json → ai_constraints.ai_framework.value to determine format.

"llm_router" → Generate gateway_config.yaml (LiteLLM format):

  • Map each model from aws-design-ai.json to a bedrock/MODEL_ID entry with aws_region_name

  • Include embedding model entry if embeddings are used

  • Note required env vars: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION

"llm_router" + OpenRouter detected (evidence: base_url containing openrouter.ai in ai-workload-profile.json → detection_signals):

Check aws-design-ai.json → code_migration.openrouter_path (set in Design Part 5):

  • "direct" → Skip gateway config. Generate provider adapter instead (same as Step 1 for direct SDK users). Note: "Migrating from OpenRouter to direct Bedrock API removes the routing middleman and OpenRouter's margin."

  • "litellm" → Generate gateway_config.yaml in LiteLLM format (standard llm_router logic above) + add header comment: "# Migration from OpenRouter to self-hosted LiteLLM with Bedrock backend\n# Install: pip install litellm\n# Run: litellm --config gateway_config.yaml"

  • "keep_openrouter" → Generate gateway_config.json with OpenRouter model ID mappings:

    {
      "models": {
        "original_model_id": "amazon/{bedrock_model_id}",
        "original_embedding_id": "amazon/{titan_embedding_model_id}"
      },
      "notes": "OpenRouter adds margin on top of provider pricing. Compare OpenRouter pricing vs direct Bedrock pricing in your cost estimate."
    }
  • If openrouter_path is absent: default to "litellm" (standard LiteLLM config generation)

"framework" → Generate gateway_config.py:

  • Show before/after import swap for the detected framework (ai-workload-profile.json → integration.sdk_imports)

  • LangChain: langchain_google_vertexai → langchain_aws.ChatBedrock (or langchain_openai → langchain_aws.ChatBedrock)

  • LlamaIndex: llama_index.llms.vertex → llama_index.llms.bedrock_converse

  • Include pip install note for the AWS package

"voice_platform" → Generate gateway_config.json:

  • Dashboard configuration steps: add Bedrock as provider, set model ID, set region, test before switching production

  • Include the Bedrock model ID and region from design artifacts

"api_gateway" → Generate gateway_config.yaml:

  • Upstream URL: https://bedrock-runtime.{region}.amazonaws.com

  • Auth: AWS SigV4 signing for the bedrock service

  • Note: Converse API endpoint is POST /model/{modelId}/converse

  • Include gateway-specific notes (Kong plugin, Apigee policy)


Step 3C: Generate AgentCore Harness Artifacts (Harness Users Only)

Skip if aws-design-ai.json → agentic_design is absent OR agentic_design.migration_approach != "harness".

Read aws-design-ai.json → agentic_design.harness_config for all configuration values.

Artifact 1: ai-migration/harness.json

Generate the Harness configuration file:

{
  "name": "{harness_config.name}",
  "model": "{harness_config.model_id}",
  "systemPrompt": "{harness_config.system_prompt}",
  "tools": [
    // Each tool from harness_config.tools, mapped to Harness tool format:
    // remote_mcp: {"type": "remote_mcp", "name": "...", "config": {"remoteMcp": {"url": "..."}}}
    // agentcore_browser: {"type": "agentcore_browser", "name": "browser"}
    // agentcore_code_interpreter: {"type": "agentcore_code_interpreter", "name": "code_interpreter"}
    // agentcore_gateway: {"type": "agentcore_gateway", "name": "...", "config": {"agentCoreGateway": {"gatewayArn": "[TODO: Gateway ARN]"}}}
    // inline_function: {"type": "inline_function", "name": "...", "config": {"inlineFunction": {"description": "...", "inputSchema": {...}}}}
  ]
}

Use actual values from harness_config — no placeholders except where noted with [TODO: ...]. Include a comment header explaining the file's purpose.

Artifact 2: ai-migration/deploy_harness.sh

Generate deployment script. Dry-run by default (--execute flag to run for real).

#!/bin/bash
# AgentCore Harness Deployment Script
# Generated by GCP-to-AWS migration plugin
# Run with --execute to perform actual deployment (default: dry-run)
set -euo pipefail

EXECUTE=${1:-""}
HARNESS_NAME="{harness_config.name}"
MODEL_ID="{harness_config.model_id}"
REGION="{target_region from preferences.json}"

run_cmd() {
    if [ "$EXECUTE" = "--execute" ]; then
        echo ">>> $*"
        eval "$@"
    else
        echo "[DRY-RUN] $*"
    fi
}

echo "=== AgentCore Harness Deployment: $HARNESS_NAME ==="
echo "Model: $MODEL_ID"
echo "Region: $REGION"
echo ""

# Step 1: Verify AgentCore CLI is installed
if ! command -v agentcore &> /dev/null; then
    echo "AgentCore CLI not found. Install with:"
    echo "  pip install bedrock-agentcore-cli"
    if [ "$EXECUTE" != "--execute" ]; then
        echo "[DRY-RUN] Continuing with remaining steps..."
    else
        exit 1
    fi
fi

# Step 2: Create project
run_cmd "agentcore create --name $HARNESS_NAME"

# Step 3: Add harness with model and tools
run_cmd "agentcore add harness --name $HARNESS_NAME \\
  --model-id $MODEL_ID \\
  --system-prompt '{harness_config.system_prompt}' \\
  --tools {comma-separated tool types from harness_config.tools}"

# Step 4: Deploy
run_cmd "agentcore deploy"

# Step 5: Test invocation
echo ""
echo "=== Test Invocation ==="
run_cmd "agentcore invoke --harness $HARNESS_NAME \\
  'Hello, this is a test invocation to verify deployment.'"

echo ""
echo "=== Deployment Complete ==="
echo "Next steps:"
echo "  1. Test with representative prompts: agentcore invoke --harness $HARNESS_NAME 'your prompt'"
echo "  2. Override model for A/B testing: agentcore invoke --harness $HARNESS_NAME --model-id <alt-model> 'prompt'"
echo "  3. View logs: agentcore logs --harness $HARNESS_NAME"

Artifact 3: ai-migration/incremental_migration.sh (only if harness_config.incremental_migration == true)

Generate incremental migration script showing multi-model switching:

#!/bin/bash
# Incremental Migration: Source Provider → Bedrock via AgentCore Harness
# This script demonstrates the multi-model switching capability.
# Run each phase manually and validate before proceeding to the next.
set -euo pipefail

HARNESS_NAME="{harness_config.name}"
SOURCE_PROVIDER="{harness_config.source_model_provider}"
SOURCE_MODEL="{harness_config.source_model_id}"
BEDROCK_MODEL="{harness_config.model_id}"
SESSION_ID=$(uuidgen)

echo "=== Incremental Migration Plan ==="
echo "Source: $SOURCE_PROVIDER / $SOURCE_MODEL"
echo "Target: Bedrock / $BEDROCK_MODEL"
echo "Session: $SESSION_ID"
echo ""

# Phase 0: Store source provider API key in AgentCore Identity
echo "--- Phase 0: Configure source provider credentials ---"
echo "Run once:"
echo "  agentcore add credential --type api-key --name source-provider-key --api-key \$SOURCE_API_KEY"
echo "  agentcore deploy"
echo ""

# Phase 1: Invoke with source provider model on AgentCore infrastructure
echo "--- Phase 1: Source provider on AgentCore ---"
echo "agentcore invoke --harness $HARNESS_NAME \\"
echo "  --model-provider $SOURCE_PROVIDER \\"
echo "  --model-id $SOURCE_MODEL \\"
echo "  --api-key-arn arn:aws:bedrock-agentcore:{region}:{account}:token-vault/default/apikeycredentialprovider/source-provider-key \\"
echo "  --session-id $SESSION_ID \\"
echo "  'Your test prompt here'"
echo ""

# Phase 2: Same session, switch to Bedrock model
echo "--- Phase 2: Bedrock model (same session, context preserved) ---"
echo "agentcore invoke --harness $HARNESS_NAME \\"
echo "  --model-id $BEDROCK_MODEL \\"
echo "  --session-id $SESSION_ID \\"
echo "  'Same test prompt for comparison'"
echo ""

# Phase 3: Update default model
echo "--- Phase 3: Switch default to Bedrock ---"
echo "Edit app/$HARNESS_NAME/harness.json: set \"model\" to \"$BEDROCK_MODEL\""
echo "agentcore deploy"
echo ""

# Phase 4: Remove source provider
echo "--- Phase 4: Clean up source provider credentials ---"
echo "After 48h stable on Bedrock:"
echo "  Remove API key from AgentCore Identity"
echo "  agentcore deploy"
echo ""
echo "=== Migration Complete ==="

Step 3D: Generate Evaluation Artifacts (If User Opted In)

Skip if the user did not opt into model evaluation in generate-ai.md Part 0.

eval-prompts.jsonl: Generate 10-20 domain-specific prompts in JSONL format ({"prompt": "...", "referenceResponse": "", "category": "..."}). Base prompts on ai-workload-profile.json → models[].usage_context. Include function-calling prompts if capabilities_summary.function_calling is true, retrieval prompts if RAG patterns were detected. Include 2-3 edge case prompts.

run-evaluation.sh: Dry-run by default. Creates S3 bucket, uploads prompts, calls aws bedrock create-evaluation-job with model IDs from aws-design-ai.json, downloads results. Use the same model IDs and region as setup_bedrock.sh.


Step 3E: Generate Strands Migration Artifacts (Strands Users Only)

Skip if aws-design-ai.json → agentic_design is absent OR agentic_design.migration_approach != "strands".

Read aws-design-ai.json → agentic_design.strands_config for all configuration values.

Artifact 1: ai-migration/strands_agents.py

Generate Strands agent definitions from the design config. For each agent in strands_config.agents:

"""
Strands Agents Migration — Generated by GCP-to-AWS migration plugin
Source framework: {strands_config.source_framework}
Orchestration: {strands_config.orchestration_primitive}

Install: pip install strands-agents strands-agents-tools boto3
Docs: https://strandsagents.com
"""
from strands import Agent, tool
from strands.models import BedrockModel

# Model configuration
model = BedrockModel(
    model_id="{agents[0].model_id}",
    region_name="{target_region}"
)

# --- Tool definitions ---
# Migrate your existing tool functions by adding the @tool decorator.
# Your tool logic stays the same; Strands handles invocation and result parsing.

@tool
def {tool_name}({params}) -> str:
    """[TODO: Your existing tool description]"""
    # [TODO: Paste your existing tool implementation here]
    pass

# --- Agent definitions ---
{agent_name} = Agent(
    name="{agent_id}",
    model=model,
    system_prompt="""{system_prompt}""",
    tools=[{tool_list}]
)

For multi-agent systems, generate the orchestration based on orchestration_primitive:

  • agents_as_tools (hierarchical):

# Specialist agents wrapped as tools for the orchestrator
@tool
def {specialist_agent_id}(query: str) -> str:
    """[role description]"""
    response = {specialist_var}(query)
    return str(response)

# Orchestrator delegates to specialists
orchestrator = Agent(
    name="orchestrator",
    model=model,
    tools=[{specialist_tool_1}, {specialist_tool_2}, ...]
)

result = orchestrator("Your task here")
  • swarm (collaborative):

from strands.multiagent import Swarm

team = Swarm([{agent_1}, {agent_2}, {agent_3}])
result = team("Your task here")
  • graph (deterministic workflow):

from strands.multiagent import GraphBuilder

builder = GraphBuilder()
builder.add_node({agent_1}, "{node_1_name}")
builder.add_node({agent_2}, "{node_2_name}")
builder.add_edge("{node_1_name}", "{node_2_name}")  # Add conditions if detected
builder.set_entry_point("{entry_node}")
workflow = builder.build()

result = workflow("Your task here")
  • single_agent: Just the single Agent definition (no multi-agent orchestration).

Use actual agent IDs, model IDs, tool names, and system prompts from the design config. Mark TODOs only where implementation details can't be extracted from discovery.

Artifact 2: ai-migration/deploy_strands.sh

Generate AgentCore Runtime deployment script. Dry-run by default.

#!/bin/bash
# Strands Agents — AgentCore Runtime Deployment
# Generated by GCP-to-AWS migration plugin
# Run with --execute to perform actual deployment (default: dry-run)
set -euo pipefail

EXECUTE=${1:-""}
PROJECT_NAME="{agent_id}-strands"
REGION="{target_region}"

run_cmd() {
    if [ "$EXECUTE" = "--execute" ]; then
        echo ">>> $*"
        eval "$@"
    else
        echo "[DRY-RUN] $*"
    fi
}

echo "=== Strands Agents — AgentCore Runtime Deployment ==="
echo "Project: $PROJECT_NAME"
echo "Region: $REGION"
echo "Agents: {agent_count}"
echo ""

# Step 1: Verify dependencies
echo "--- Prerequisites ---"
run_cmd "pip install strands-agents strands-agents-tools boto3 bedrock-agentcore-cli"

# Step 2: Create AgentCore project
run_cmd "agentcore create --name $PROJECT_NAME"

# Step 3: Deploy to AgentCore Runtime
echo ""
echo "--- Deploying to AgentCore Runtime ---"
run_cmd "agentcore deploy"

# Step 4: Test invocation
echo ""
echo "--- Test Invocation ---"
run_cmd "agentcore invoke --name $PROJECT_NAME 'Hello, test invocation'"

echo ""
echo "=== Deployment Complete ==="
echo "Next steps:"
echo "  1. Run locally first: python strands_agents.py"
echo "  2. Test with representative prompts"
echo "  3. Deploy: ./deploy_strands.sh --execute"
echo "  4. Monitor: agentcore logs --name $PROJECT_NAME"
echo ""
echo "Strands docs: https://strandsagents.com"
echo "AgentCore docs: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/"

Artifact 3: ai-migration/bridge_retarget.py (only if strands_config.bridge_phase == true)

Generate a partial retarget bridge for OpenAI Agents SDK users — routes model calls through Bedrock while keeping existing orchestration temporarily:

"""
Bridge: OpenAI Agents SDK → Bedrock (via OpenAI-compatible endpoint)
This is a temporary bridge. Use while migrating orchestration to Strands.

This works because Bedrock's Converse API can be accessed through an
OpenAI-compatible proxy, allowing your existing OpenAI Agents SDK code
to call Bedrock models without code changes.

After validating Bedrock model quality, migrate to Strands for full
AWS-native agent capabilities.
"""
import os

# Option A: Use LiteLLM as OpenAI-compatible proxy to Bedrock
# pip install litellm
# Set: OPENAI_API_BASE=http://localhost:4000  (LiteLLM proxy)
# LiteLLM config: model_list: [{model_name: "gpt-4o", litellm_params: {model: "bedrock/{bedrock_model_id}"}}]

# Option B: Use Bedrock's OpenAI-compatible endpoint (if available)
# Set: OPENAI_API_BASE=https://bedrock-runtime.{region}.amazonaws.com/openai/v1
# Set: OPENAI_API_KEY=<not used, auth via SigV4>

# Your existing OpenAI Agents SDK code continues to work unchanged.
# The model calls route through Bedrock instead of OpenAI.

BRIDGE_CONFIG = {
    "source_model": "{source_model_id}",
    "target_model": "bedrock/{bedrock_model_id}",
    "proxy": "litellm",  # or "bedrock_openai_compat"
    "region": "{target_region}",
    "note": "Temporary bridge. Migrate to Strands (strands_agents.py) when ready."
}

print(f"Bridge configured: {BRIDGE_CONFIG['source_model']} → {BRIDGE_CONFIG['target_model']}")
print(f"Next step: Validate model quality, then migrate to Strands.")


Step 3F: Generate Bedrock Cost Monitoring Terraform

Runs for ALL migration paths (direct, mantle, gpt-oss, gateway, harness, strands). Creates ai-migration/bedrock_monitoring.tf — standalone Terraform for AI-only migrations that have no baseline.tf from the infra track.

These are detective controls, not spend caps. Bedrock has no native spend limit. Anomaly Detection has ~24h data lag — you'll know within a day, not at month-end invoice. AI-only migrations (infra stays on GCP) have zero cost guardrails without this file.

Seed budget threshold: Read estimation-ai.json → cost_comparison.projected_bedrock_monthly. Round up to nearest integer. If absent, use 50 as the default.

Emit the final computed integer directly in limit_amount — do not emit an expression.

# ============================================================
# Bedrock Cost Monitoring — Generated by GCP to AWS Migration Advisor
#
# DETECTIVE CONTROLS, NOT SPEND CAPS. Bedrock has no native
# spend limit. Anomaly Detection has ~24h data lag.
# ============================================================

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.66"  # aws_bedrock_inference_profile requires >= 5.66
    }
  }
}

provider "aws" {
  region = "{target_region}"  # from preferences.json design_constraints.target_region
}

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

variable "project_name" {
  description = "Project name for resource naming and tagging"
  type        = string
}

variable "alert_email" {
  description = "Email address for Bedrock cost alert notifications"
  type        = string
}

variable "environment" {
  description = "Deployment environment (dev, staging, prod)"
  type        = string
  default     = "prod"
}

variable "app_name" {
  description = "Application name for cost attribution tags"
  type        = string
  default     = "migration"
}

# Bedrock-scoped monthly budget
# Uses 1.5x multiplier (vs 1.2x in baseline.tf account-wide budget) because
# Bedrock token costs are more volatile than infrastructure.
# For hybrid runs: coexists with baseline.tf account-wide budget — different scopes, no conflict.
resource "aws_budgets_budget" "bedrock_spend" {
  name         = "${var.project_name}-bedrock-monthly"
  budget_type  = "COST"
  limit_amount = "{projected_bedrock_monthly_times_1.5_as_integer}"  # AGENT: replace with ceil(projected * 1.5), min 10
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "Service"
    values = ["Amazon Bedrock"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = [var.alert_email]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = [var.alert_email]
  }
}

# Bedrock anomaly detection — DIMENSIONAL/SERVICE monitors all services independently.
# A Bedrock spend spike will surface as an anomaly for the SERVICE=AmazonBedrock dimension.
# Note: DIMENSIONAL monitors all services; the budget above is Bedrock-scoped via cost_filter.
resource "aws_ce_anomaly_monitor" "bedrock" {
  name             = "${var.project_name}-bedrock-anomaly"
  monitor_type     = "DIMENSIONAL"
  monitor_dimension = "SERVICE"
}

resource "aws_ce_anomaly_subscription" "bedrock_alert" {
  name      = "${var.project_name}-bedrock-anomaly-alert"
  frequency = "DAILY"

  monitor_arn_list = [aws_ce_anomaly_monitor.bedrock.arn]

  subscriber {
    address = var.alert_email
    type    = "EMAIL"
  }

  threshold_expression {
    dimension {
      key           = "ANOMALY_TOTAL_IMPACT_PERCENTAGE"
      values        = ["50"]
      match_options = ["GREATER_THAN_OR_EQUAL"]
    }
  }
}

# Application inference profiles — cost attribution by environment/app
# Tags on these profiles appear in Cost Explorer; tags on API calls do not.
# copy_from must be a full foundation-model ARN or cross-region inference profile ARN.
# For Claude models, use the cross-region inference profile ARN format:
#   arn:aws:bedrock:{region}:{account_id}:inference-profile/us.anthropic.claude-sonnet-4-6
# For Amazon Nova models, use:
#   arn:aws:bedrock:{region}:{account_id}:inference-profile/us.amazon.nova-pro-v1:0
# [AGENT: generate one block per model in aws-design-ai.json → ai_architecture.bedrock_models[]]
resource "aws_bedrock_inference_profile" "primary" {
  name = "${var.project_name}-${var.environment}-primary"

  model_source {
    # Use cross-region inference profile ARN, not bare model ID
    copy_from = "arn:aws:bedrock:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:inference-profile/{cross_region_inference_profile_id}"
    # AGENT: replace {cross_region_inference_profile_id} with the correct ID from
    # aws-design-ai.json bedrock_models[].aws_model_id, prefixed with "us." for US regions
    # e.g., us.anthropic.claude-sonnet-4-6 or us.amazon.nova-pro-v1:0
  }

  tags = {
    Project     = var.project_name
    Environment = var.environment
    Application = var.app_name
    ManagedBy   = "terraform"
  }
}

output "bedrock_inference_profile_arns" {
  value = {
    primary = aws_bedrock_inference_profile.primary.arn
  }
  description = "Use these ARNs as BEDROCK_INFERENCE_PROFILE_ARN env var in your adapter for cost attribution"
}

Step 4: Self-Check

Verify all generated artifacts:

  • [ ] Provider adapter (or gateway config) uses actual model IDs from aws-design-ai.json — no placeholders

  • [ ] Only capabilities present in capabilities_summary have methods/tests generated

  • [ ] Feature flag (AI_PROVIDER env var) controls provider selection in adapter

  • [ ] Test harness includes domain-specific prompts from usage_context

  • [ ] Test harness produces structured JSON output with latency and quality metrics

  • [ ] Setup script has correct region from preferences.json

  • [ ] Setup script IAM role follows least privilege

  • [ ] All scripts default to dry-run mode

  • [ ] Evaluation artifacts (if generated) have correct model IDs and region

  • [ ] No hardcoded credentials in any file

  • [ ] bedrock_monitoring.tf generated with budget limit_amount as computed integer (not expression)

  • [ ] Budget limit_amount = ceil(projected_bedrock_monthly * 1.5), minimum 10

  • [ ] Anomaly monitor uses monitor_type = "DIMENSIONAL" with monitor_dimension = "SERVICE" (no monitor_specification)

  • [ ] Inference profile copy_from uses full ARN format, not bare model ID

  • [ ] Provider adapter references BEDROCK_INFERENCE_PROFILE_ARN env var with model ID fallback

  • [ ] alert_email variable declared in bedrock_monitoring.tf

  • [ ] If Harness artifacts generated: harness.json uses actual model ID from agentic_design.harness_config.model_id

  • [ ] If Harness artifacts generated: harness.json tool types match tool_manifest[].transport mapping

  • [ ] If Harness artifacts generated: deploy_harness.sh defaults to dry-run

  • [ ] If Harness artifacts generated: incremental_migration.sh only present when incremental_migration == true

  • [ ] If OpenRouter path: artifact type matches code_migration.openrouter_path value

  • [ ] If Strands artifacts generated: strands_agents.py uses actual model IDs, agent IDs, and tool names from design config

  • [ ] If Strands artifacts generated: orchestration primitive matches strands_config.orchestration_primitive

  • [ ] If Strands artifacts generated: bridge_retarget.py only present when strands_config.bridge_phase == true

  • [ ] If Strands artifacts generated: deploy_strands.sh defaults to dry-run

Phase Completion

Report generated files to the parent orchestrator. Do NOT update .phase-status.json — the parent generate.md handles phase completion.

Output:

Generated AI migration artifacts:
- ai-migration/setup_bedrock.sh
- ai-migration/test_comparison.py
- ai-migration/provider_adapter.{py|js|go}    # Direct SDK users only
- ai-migration/gateway_config.{yaml|py|json}  # Gateway users only
- ai-migration/harness.json                    # Harness users only
- ai-migration/deploy_harness.sh              # Harness users only
- ai-migration/incremental_migration.sh       # Harness + incremental only
- ai-migration/strands_agents.py              # Strands users only
- ai-migration/deploy_strands.sh              # Strands users only
- ai-migration/bridge_retarget.py             # Strands + OpenAI Agents SDK bridge only
- ai-migration/bedrock_monitoring.tf          # Always — Bedrock budget, anomaly detection, inference profiles
- ai-migration/eval-prompts.jsonl              # If evaluation opted in
- ai-migration/run-evaluation.sh               # If evaluation opted in

Gateway type: [ai_framework value]
Language: [detected language]
Models to migrate: [count] models
Capabilities covered: [list from capabilities_summary]

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