launch-with-aws

使用 AWS 启动

通过 CLI 脚本端到端地完成 AWS 迁移。接收用户的 Web 应用，对其进行分析，生成包含成本估算的迁移计划，并提供可部署的 AWS Blocks 基础设施代码。

建议使用 AWS MCP 服务，但并非必需。此技能可通过 CLI 脚本在任何 Agent 环境中独立运行。

脚本调用

所有命令均通过以下方式运行：

python3 scripts/launch_with_aws.py <command> [args...]

其中，scripts/ 是相对于此技能目录的路径。Agent 在调用命令前必须将工作目录设为技能根目录。

所需文件：launch_with_aws.py、launch_config.py、auth.py、auth_callback_server.py、launch_api_client.py、archive.py、服务模型。通过 MCP 加载时，请获取所有文件，并在调用前写入临时目录，同时保留目录结构。

成功时，每条命令都会向 stdout 输出 JSON；如果失败，则以非零状态码退出，并向 stderr 输出 JSON 错误。

每条命令都可以添加两个全局标志：--region <region> 用于选择服务执行迁移的区域；--aws-mcp-url <url> 用于传递 Agent 所连接的 AWS MCP 服务 URL。请参阅步骤 2。

依赖项：Python 3.10+ 和 boto3。脚本启动时会检查这两项；若有缺失，则会显示明确的错误并退出。

支持的应用类型

使用 vibe-coding 平台构建的全栈应用，以及前端 Web 应用和网站（静态站点、SPA 和支持静态导出的 SSR 框架）。

来源平台	覆盖范围
Lovable	Lovable 生成的全栈应用（React + Supabase）
Bolt.new	Bolt.new 生成的全栈应用（React + Supabase）
Replit	托管于 Replit 的全栈应用（React + Express.js + PostgreSQL）

框架	示例
React 生态系统	React、CRA、Vite + React、Gatsby、Docusaurus
Vue 生态系统	Vue、Nuxt（静态导出）、VitePress
Angular	Angular
Svelte 生态系统	Svelte、SvelteKit（静态导出）
支持静态导出的 SSR	Next.js、Nuxt、Astro、SvelteKit
其他现代框架	Astro、Solid、Preact、Lit、Eleventy
Vite（通用）	任何基于 Vite 的应用

其他框架也可能适用。如果用户的应用不符合这些类型，请参阅下文的不支持的应用处理方式。

迁移内容与保留内容

Lovable / Bolt.new 应用（由 Supabase 提供支持）：

组件	处理方式
前端与托管	迁移到 AWS（S3 + CloudFront + Lambda）
Edge 函数 / 服务端函数	迁移到 AWS Lambda
AI 调用（例如 Lovable AI Gateway）	迁移到 Amazon Bedrock
数据库（Supabase DB）	保留在 Supabase 上 — 不迁移
身份验证（Supabase Auth）	保留在 Supabase 上 — 不迁移
存储与 Realtime	保留在 Supabase 上 — 不迁移

该应用会继续从托管在 AWS 上的应用调用 Supabase，以使用数据库、身份验证、存储和 Realtime。

Replit 应用（Express.js + PostgreSQL）：

组件	处理方式
前端与托管	迁移到 AWS（S3 + CloudFront + Lambda）
服务端逻辑（Express.js）	迁移到 AWS Lambda（API Gateway）
数据库（PostgreSQL）	架构和代码迁移到 AWS（Aurora Serverless / DynamoDB）。现有数据不会迁移 — 客户必须另行导出并导入数据。
身份验证（Replit Auth）	代码迁移到 AWS（Cognito）。现有用户帐户不会迁移 — 客户必须在 Cognito 中重新创建用户或邀请用户。
Realtime（WebSockets）	迁移到 AWS（API Gateway WebSocket）
文件存储	迁移到 AWS（S3）。现有文件不会迁移。

Replit 应用的基础设施和代码会迁移到 AWS 原生服务，但现有数据、用户帐户和文件必须由客户另行迁移。

输入解析

将用户输入解析为本地目录路径：

• 如果用户提供了本地路径：直接传入该路径。
• 如果用户提供了GitHub URL：在本地克隆仓库并使用该目录。
• 如果两者都未提供：使用当前工作目录。如果它看起来不像应用目录，请向用户询问路径。

流程

按顺序运行脚本命令，并在每个步骤向用户展示结果：

1. 身份验证

python3 scripts/launch_with_aws.py auth-start

务必首先运行。会立即返回 JSON：

• 如果已通过身份验证：{"authenticated": true, "reusedCachedSession": true, "baseUrl": "..."}
• 如果静默刷新成功：{"authenticated": true, "reusedCachedSession": false, "baseUrl": "..."}
• 如果需要交互式登录：{"authenticated": false, "signInUrl": "https://...", "pid": 12345, "port": 54321, "baseUrl": "..."}

当 authenticated 为 false 时，立即向用户显示 signInUrl（以便他们在浏览器中打开），并在同一响应中调用 auth-wait：

python3 scripts/launch_with_aws.py auth-wait <pid>

其中 <pid> 是 auth-start 响应中的 pid 值。此命令会一直阻塞，直到用户完成浏览器登录（或在 600s 后超时）。成功时返回 {"authenticated": true, "baseUrl": "..."}。

即使身份提供商未设置过期时间，会话最长也为 90 天；之后必须再次进行交互式身份验证。

如需在不进行身份验证的情况下检查当前会话，或退出登录：

python3 scripts/launch_with_aws.py session-status
python3 scripts/launch_with_aws.py sign-out

session-status 会报告会话是否存在，以及令牌和整个会话距离过期还有多长时间。sign-out 会尽力撤销刷新令牌，并删除本地的 ~/.launch-with-aws/session.json。在共享或不受信任的工作站上，使用完毕后请运行 sign-out。

2. 创建启动任务

对于本地目录，请原样呈现以下数据处理确认内容，并等待用户明确批准：

您的源代码将上传到 [regionName], [region]（[sourceLabel]）中的 Launch with AWS 服务，以分析您的应用并生成迁移计划。如果您之后批准执行，AWS 托管的 Agent 将根据该计划修改您的源代码副本，并生成可供您下载的迁移快照。您上传的源代码及相关启动任务数据在传输中和静态存储时均经过加密，并最多保留 48 小时以供恢复。您的数据绝不会用于训练 AI 模型。我们会排除 Git 历史记录、Git 忽略的文件，以及与常见敏感文件模式匹配的文件。敏感文件筛选只能尽力而为；请检查您的项目是否包含机密信息。是否继续？或者回复 [otherRegions regionName]，改为在该区域运行迁移。

从 resolve-region 原样填入区域字段，并将每个 otherRegions 条目作为备选项提供。如果 Agent 已连接到 AWS MCP 服务，请原样传入该服务的 URL。脚本会从中读取区域，并判断它是否算作信号。

python3 scripts/launch_with_aws.py resolve-region [--aws-mcp-url https://aws-mcp.<region>.api.aws/mcp]

返回 {"region": ..., "regionName": ..., "source": ..., "sourceLabel": ..., "baseUrl": ..., "otherRegions": [{"region": ..., "regionName": ...}]}。

在用户明确确认之前，不要调用 create-launch；缺少回复或回复含糊都视为否。指定某个 otherRegions 条目既代表选择区域，也代表批准——将其 region 作为 --region 传入，不要再次询问。

python3 scripts/launch_with_aws.py create-launch <app-directory> [name] --region <region>

将目录压缩为 ZIP 文件并上传，然后创建启动任务。返回包含 launch.launchId 和创建该启动任务所在 region 的完整 launch 对象，该区域将成为用户保存的默认区域。启动任务仅存在于其所在区域——后续每条命令都要传入其 --region。

启动任务的初始状态为 analyzing，随后会自动推进分析和规划阶段。

3. 轮询启动任务状态

python3 scripts/launch_with_aws.py get-launch-status <launch-id> --region <region>

轮询，直到 status 为 planned（已准备好执行）或 failed；其他状态都应告知用户。主要状态进展如下：

• analyzing → 正在检测应用类型和依赖项
• planning → 正在生成迁移计划
• planned → 已准备好执行
• executing → 部署正在进行
• completed → 已完成
• failed → 检查 failureReason

4. 获取完整启动任务详情并确认

python3 scripts/launch_with_aws.py get-launch <launch-id> plan,cost_estimate --region <region>

获取完整的启动任务详情。可选的第二个参数是以逗号分隔的包含项列表：analysis、plan、execution、cost_estimate、download_url。

向用户展示成本估算和计划。响应中的 costEstimate 字段包含 estimatedMonthlyCost、region，以及按服务细分的 services 成本明细。

确认关卡——展示以下内容并等待用户明确批准：

迁移摘要

• 应用类型：[analysis 中检测到的类型]
• 架构：[plan 中的目标架构]
• 预计月费用：$X.XX/月（按 [costEstimate.region] 的价格计算）
• 迁移运行区域：[regionName], [region]

准备好继续了吗？这将会在 AWS 托管环境中执行迁移（您无需承担费用），并生成可供您下载的迁移快照。

在用户明确确认之前，不要调用 start-launch-execution。

5. 开始执行

python3 scripts/launch_with_aws.py start-launch-execution <launch-id> --region <region>

开始部署。然后使用 get-launch-status 进行轮询，直到 status 为 completed 或 failed。两次轮询之间至少等待 30 秒。

6. 下载

python3 scripts/launch_with_aws.py get-launch-download-url <launch-id> --region <region>

始终向用户提供完整的下载 URL——用户可能需要通过该 URL 直接下载迁移快照，或将其用于参考。

7. 列出或删除启动任务

python3 scripts/launch_with_aws.py list-launches
python3 scripts/launch_with_aws.py delete-launch <launch-id> --region <region>

list-launches 会查询两个区域，并返回每个启动任务都带有 region 的 items；添加 --region 可只查询一个区域。无法访问的区域会列在 errors 下，而不会导致命令失败；除非所有查询的区域都失败，此时命令会以相应错误退出。

8. 迁移后：在本地应用迁移后的代码

获取下载 URL 后（如果不是 POSIX 平台，请调整命令以适配用户的平台）：

步骤 A：下载并解压

curl -L -o /tmp/migration-snapshot.zip "<download_url>"
mkdir -p /tmp/migration-output
unzip -o /tmp/migration-snapshot.zip -d /tmp/migration-output

步骤 B：准备本地工作区

确保用户的工作目录干净：

cd <user-app-directory>
git status

如果存在未提交的更改，请先让用户提交或暂存更改。工作树不干净时，切勿继续。

步骤 C：应用迁移（3 路合并）

创建迁移分支并覆盖迁移后的文件：

cd <user-app-directory>
git checkout -b aws-migration
rsync -a /tmp/migration-output/ .
git status
git diff --stat

与用户一起检查更改。需要重点介绍的内容：

• aws-blocks/ — AWS Blocks 基础设施定义
• DEPLOY.md — 部署说明
• 任何已修改的配置文件

如果与用户现有文件发生冲突，请展示冲突并询问如何解决。

步骤 D：遵循 DEPLOY.md

读取项目根目录中的 DEPLOY.md 文件，并按照其中的说明将应用部署到用户的 AWS 账户。典型步骤：

1. AWS 身份验证（aws login --profile aws-migrate --region us-east-1）
2. CDK 引导（仅首次需要）：npm install && npx cdk bootstrap
3. 部署：npx cdk deploy --all --progress events
4. 验证 CDK 完成时输出的 CloudFront URL。

**重要：**务必读取迁移后输出中的 DEPLOY.md — 它是专门针对此应用及其架构生成的。不要凭记忆推断部署步骤。

不支持的应用处理方式

如果分析期间启动失败，且 failureReason 表明应用类型不受支持（或用户的技术栈与受支持列表不匹配）：

1. 告诉用户：“Launch with AWS 暂不直接支持此应用类型。我来搜索其他有助于部署此类应用的技能。”

2. 根据应用类型搜索相关技能（例如 aws-serverless、aws-containers、aws-database、aws-deployment、aws-cdk、aws-ai-ml）。