AWS 应用托管部署实战：App Runner vs Elastic Beanstalk 怎么选（含从 0 上线全流程）

Meta Description: AWS App Runner 与 Elastic Beanstalk 深度对比实战：源码/镜像一键上线、从 0 部署完整步骤、2026 真实单价与官方成本算例、Cloud Map 服务发现与 AWS Batch 批处理、11 维选型对比表、7 大坑与 FAQ。

关键词：AWS App Runner、AWS Elastic Beanstalk、AWS 应用托管、容器部署实战、PaaS 托管、AWS 免费套餐、AWS 教程

写一个后端服务，让人头疼的往往不是写不出代码，而是"代码写完了，服务器还没配好"。在 AWS 上"不用管服务器就能把应用跑起来"的托管服务其实是一整排：Lambda、App Runner、Elastic Beanstalk、ECS/Fargate、EKS、Lightsail……很多人的第一反应是"随便挑一个"，结果要么挑了个过度复杂的（EKS），要么挑了个跑不了长连接的（Lambda），上线一周才发现账单或架构都不对。

决策口诀先给结论：

• 只想把源码或镜像变成一个带 HTTPS 的服务、不想碰任何基础设施 → AWS App Runner（本文主角一）
• 传统 Web 应用（Java/PHP/.NET）需要整套运行环境、需要 SSH 进去调、需要自定义服务器配置 → AWS Elastic Beanstalk（本文主角二）
• 要跑容器编排、要精细控制调度策略 → ECS + Fargate 或 EKS
• 事件驱动、无状态短任务 → Lambda
• 离线批处理、跑完即止 → AWS Batch

本文不空谈概念，而是把这两个"托管部署"主角放进同一篇：它们的真实单价、从 0 上线的完整步骤、11 维横向对比、成本测算，以及同家族里两个常被忽略的兄弟（Cloud Map 服务发现、Batch 批处理）。文中的价格均为 2026 年 10 月采集的 AWS 官方口径（us-east-1 为主），实际费用随区域和官方调价变动，请以官网为准。

一、先划边界：六种"跑应用"的方式到底怎么选

在动手之前，先花两分钟把"托管"这个词拆开。AWS 上这些服务分成两类：全托管（你连操作系统的影子都看不到，比如 Lambda、App Runner）与半托管（AWS 帮你把资源配好，但机器仍然躺在你的账号里、你能登进去，比如 Elastic Beanstalk、ECS、EKS）。

一句话总结这两个主角的分野：App Runner 是"我给你代码，你别问服务器"；Elastic Beanstalk 是"我帮你把服务器配好，但机器还是你的"。 前者极致省心，后者极致灵活。选错了不会马上出问题，但会在"我想改一行服务器配置"或"我想省一点钱"的那一刻集中爆发。

二、AWS App Runner 是什么：把源码或镜像一键跑成 HTTPS 服务

AWS App Runner 是一个全托管的容器化 Web 应用运行服务。你只需要提供两样东西之一：一段源码（从 GitHub / CodeCommit 拉取），或者一个已经打好包的容器镜像（存放在 Amazon ECR）。App Runner 会替你完成剩下全部事情：

• 自动构建：拿到源码后自动生成容器镜像（这一步会产生"构建费"，见下一节）。
• 自动部署与负载均衡：流量进来时自动加实例，空闲时缩回。
• 自动配置 HTTPS：每个服务默认自带 https://xxxx.us-east-1.awsapprunner.com 域名，无需自己申请证书即可加密访问。
• 健康检查与自动伸缩：内置健康检查，配合你设定的并发数（每个活动实例可同时处理的请求上限，可配置）自动扩缩。
• 支持自定义域名：绑定自己的域名时可用 ACM 证书（证书免费）。
• 支持 VPC 访问：创建服务时可传入 VPC ID、子网与安全组，让应用能访问 VPC 内的 RDS 等资源——App Runner 不为 VPC 接入单独收费，只按正常的数据传输计费。

实例规格（官方支持的全部组合）：App Runner 的实例规格是"vCPU + 内存"配对，一共 11 档，最小 0.25 vCPU / 0.5 GB，最大 4 vCPU / 12 GB。

一个必须记住的概念：App Runner 有两类容器实例。 一类是 Provisioned（预置）实例，作用是把应用"焐热"、消除冷启动，空闲时也按内存计费（默认最少 1 个）；另一类是 Active（活动）实例，真正处理请求、同时消耗 vCPU 和内存。请求来了就切到 Active，闲下来又缩回 Provisioned。这个"两段式"模型是理解 App Runner 账单的关键。

三、App Runner 从 0 部署实战（控制台 + CLI）

假设你已经有一个能跑的 Web 应用（本文以容器镜像为例）。整个上线流程分六步。

第 1 步，准备镜像。 把应用打成 Docker 镜像并推送到 Amazon ECR（Elastic Container Registry）。如果你选择"从源码部署"，App Runner 可以直连 GitHub，跳过这一步。

第 2 步，创建连接（可选但推荐）。 如果镜像在私有 ECR 或源码在私有 GitHub 仓库，需要先创建一条连接（Connection），让 App Runner 有权限拉取代码。

第 3 步，创建服务。 进入 App Runner 控制台，点"创建服务"，选择"容器镜像"或"源代码"，填入镜像地址或仓库分支。

第 4 步，配置部署触发方式。 选择"自动部署"后，代码分支或镜像标签一变就自动重新部署；选"手动部署"则每次需要手动触发一次发布。自动部署按应用收 $1/月的固定费（见下一节）。

第 5 步，配置计算与伸缩。 选择实例规格（如 1 vCPU / 2 GB）、并发数，以及"活动实例数的上限"——这个上限就是官方所称的预算刹车（budget controls），设好之后流量再涨账单也不会突破你的预算。

第 6 步，配置健康检查、环境变量、自定义域名，然后发布。

整套流程用 AWS CLI 同样可以完成，核心命令如下（把步骤说明放在命令块外面，避免注释符号被误渲染）：

创建连接与服务：

aws apprunner create-connection \
  --connection-name my-github-conn \
  --provider-type GITHUB

aws apprunner create-service \
  --service-name my-api \
  --source-configuration file://source.json \
  --instance-configuration '{"Cpu":"1 vCPU","Memory":"2 GB"}'

发布新版本 / 暂停 / 恢复（暂停后不再计费，是省钱利器）：

aws apprunner start-deployment --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-api
aws apprunner pause-service  --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-api
aws apprunner resume-service --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-api

绑定自定义域名：

aws apprunner associate-custom-domain \
  --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-api \
  --domain-name api.example.com \
  --enable-www-subdomain false

App Runner 已核实的常用命令集：create-service、update-service、delete-service、describe-service、list-services、start-deployment、pause-service、resume-service、create-connection、create-auto-scaling-configuration、create-vpc-connector、create-vpc-ingress-connection、create-observability-configuration、associate-custom-domain、disassociate-custom-domain、list-operations。

四、App Runner 计费详解：三段式账单与三个官方算例

App Runner 的账单由运行费 + 可选的自动化费 + 可选的构建费三部分组成，全部按秒计费、向上取整。

计费铁律有三条，写进成本表之前必须记住：

1. vCPU 有"一分钟最低消费"：每次 Provisioned 实例开始处理请求，vCPU 至少按 1 分钟计费，之后才按秒。
2. 暂停（Pause）之后不再计费：官方明确"只在应用运行时计费"，所以开发和测试环境用完就暂停，是极其有效的省钱手段。
3. 构建费只在首次部署或源码变更时产生，日常手动重新部署不会重复收构建费。

官方提供的三个成本算例（可直接对照自己的场景）：

从这张表能读出的最大结论：App Runner 的账单主角是运行时长 × 实例数，而不是请求数。所以"低流量但需要常驻"的服务用 App Runner 非常划算（一个月几美元），而"流量巨大、峰值常开 10 台实例"的场景，成本会迅速向 ECS/Fargate 甚至 EC2 靠拢。想控制成本，最有效的两个旋钮就是暂停和活动实例上限。

区域与免费额度（对国内/华人用户尤其重要）：App Runner 目前仅在 11 个区域可用——us-east-1、us-east-2、us-west-2、ap-south-1、ap-southeast-1（新加坡）、ap-southeast-2（悉尼）、ap-northeast-1（东京）、eu-central-1、eu-west-1、eu-west-2、eu-west-3。没有 ap-east-1 中国香港、也没有中国大陆区域，中文用户最近的可用区是东京或新加坡。另外，App Runner 的定价页没有 with AWS Free Tier 列，意味着它没有按月免费额度，只能靠账号级的 2026 免费计划额度（新账号最高 $200，详见下文 FAQ）抵扣。

五、AWS Elastic Beanstalk 是什么：老牌 PaaS 的两种新形态

Elastic Beanstalk 是 AWS 上资历最老的"托管平台"之一，定位是PaaS（平台即服务）：你上传一个代码包（Java 的 WAR、.NET 的 zip、PHP/Python/Node.js/Ruby 的源码包），它自动帮你完成容量预置、负载均衡、自动伸缩和应用部署。官方支持的语言与平台包括：Java、.NET、PHP、Node.js、Python、Ruby、Go、Docker。

与 App Runner 最大的不同在于：Beanstalk 把底层资源（EC2 实例、ELB 负载均衡器、安全组）实实在在创建在你的账号里。好处是你拥有完全的控制权——能 SSH 进去看日志、能改 Nginx/Apache 配置、能用 EC2 的预留实例和 Spot 折扣；代价是你也继承了这些资源的运维心智。

2026 年的一个重要变化：Beanstalk 现在有两种部署模式。

• Standard 模式：传统方式。你自己选 EC2 实例规格，Beanstalk 让应用跑在专用实例上——可以是一台单实例，也可以是一个随流量伸缩的 Auto Scaling 组。
• Cluster 模式：较新的方式。你只声明应用需要的 CPU 和内存，底层的 Amazon EKS Auto Mode 自动预置和管理 EC2 节点。因为多个应用可以共享节点，一个应用组合在一套集群上比各自独占实例通常更省。

一句话：Standard 是"我给每一组环境配一队专用机器"，Cluster 是"大家把容器的 CPU/内存需求丢进一个共享池"。后者更适合"有一套容器化应用矩阵"的团队。

六、Elastic Beanstalk 从 0 部署实战

用 EB CLI 部署是最顺畅的路径，四步完成（命令块外的文字就是步骤说明）：

第 1 步，初始化（在项目目录里执行，选择语言平台、是否用 Docker 等）：

eb init -p php my-app --region us-east-1

第 2 步，创建环境并首次部署：

eb create my-app-env --instance-type t3.micro

第 3 步，之后的每次发布：

eb deploy

第 4 步，打开应用、查看健康状态或进实例：

eb open
eb health
eb ssh

如果你更愿意用原生 AWS CLI，对应的命令是：创建应用 → 创建应用版本 → 创建环境。

aws elasticbeanstalk create-application --application-name my-app
aws elasticbeanstalk create-application-version \
  --application-name my-app --version-label v1 \
  --source-bundle S3Bucket=my-bucket,S3Key=app.zip
aws elasticbeanstalk create-environment \
  --application-name my-app --environment-name my-app-env \
  --solution-stack-name "64bit Amazon Linux 2023 v4.0.0 running PHP 8.1"

已核实的 Beanstalk 常用命令集：create-application、create-application-version、create-environment、create-configuration-template、update-environment、describe-environments、describe-application-versions、describe-environment-health、describe-environment-resources、terminate-environment、rebuild-environment、swap-environment-cnames（蓝绿发布用）、request-environment-info、abort-environment-update、compose-environments（组合多个环境）。

区域可用性（这是 Beanstalk 相对 App Runner 的硬优势）：Elastic Beanstalk 覆盖 31 个区域，包含 ap-east-1 中国香港，以及东京、首尔、新加坡、悉尼、孟买、台北等亚太区。也就是说，如果你的用户在大中华区，想要低延迟，Beanstalk 能在香港落地，而 App Runner 不能——这一点常常比价格更决定选型。

七、Elastic Beanstalk 计费真相：平台免费，只付底层资源

这是 Beanstalk 最容易被误解的一点，也是它最强的一句卖点：

Elastic Beanstalk 本身不额外收费。你只为它创建的 AWS 资源（例如 Amazon EC2 实例、Amazon S3 存储桶）付费。 —— AWS 官方口径

也就是说，没有平台费、没有按座位的收费、没有定价档位（no pricing tier）。你付的是底层资源的账单，而底层资源的价格和你自己手动开 EC2 完全一样。官方给了一个粗略的起步估算：一个最小化的 Standard 单实例部署（1 台 t3.micro + 8 GB EBS 根卷 + 公网 IPv4）大约 $12/月；每多加一台实例，成本增加约 $12.75/月。官方还提到，一台 t3.micro 大约能扛 25 请求/秒。

Cluster 模式的成本有两项 Standard 没有的加价：

官方给的两个 Cluster 算例：一个是"单应用、五个环境（生产+测试+开发+QA）共享一套集群"，一个是"三个应用、九个环境整合进一套集群"，用来演示应用越多、每应用摊销的固定集群费越低。

免费额度：Elastic Beanstalk 的 Standard 模式对新账号提供 6 个月的免费期（厂商把约 $12/月的起步资源成本，用 2026 免费计划的 $100–200 额度池抵扣）。但请注意两条边界：① Cluster 模式不在免费范围内；② 免费额度来自账号级的额度池，用完即止，与 Beanstalk 平台本身免费是两回事。

八、App Runner vs Elastic Beanstalk：11 维横向对比

怎么用一句话选："我的应用能装进容器、我不想管任何服务器" → App Runner；"我的应用是传统 Web 形态、我要能登机器、我要能在香港落地" → Elastic Beanstalk。

九、同家族的两个兄弟：Cloud Map 服务发现 与 AWS Batch 批处理

当你把应用"托管"起来之后，很快就会遇到两个新问题：服务之间怎么找到彼此？（服务发现）以及跑完就结束的大批量计算任务放哪儿？（批处理）。这两个问题分别对应 AWS Cloud Map 和 AWS Batch——它们同样"不用你管服务器"，也常和 App Runner / Beanstalk 搭配使用。

AWS Cloud Map —— 服务发现。 它维护一份"服务注册表"，让应用通过 API 或 DNS 查询到彼此的位置，尤其适合实例数量会动态伸缩的场景（实例一直在变，硬编码 IP 是不可能的）。计费模型很轻：

官方算例：一个由 75 台 EC2 实例 + 10 张 DynamoDB 表组成、用 HTTP 发现的应用，月成本约 $21.62（注册费 $8.5 + 发现调用 $13.12）；改用 DNS 发现、10 台实例的场景则只要 $1.67/月。结论：实例数越多、查询越频繁，Cloud Map 的费用越值得用"缓存查询结果"来压——很多团队每秒查一次完全是浪费。

AWS Batch —— 批处理。 如果你有"跑一批任务、算完就退出"的需求（数据清洗、渲染、批量转码、定时作业），Batch 负责帮你排队、按需求启动计算资源、跑完自动释放。它和 Beanstalk 一样不额外收费：

官方口径：AWS Batch 没有额外费用。你只需为它创建的资源（如 EC2 实例、Lambda 函数或 Fargate）付费。 并且可以在计费时享受你已有的预留实例、Savings Plans 和 Spot 折扣。

Cloud Map 与 Batch 都覆盖包括 ap-east-1 香港在内的亚太区域（Batch 还含 ap-east-2 台北，共 34 个区域）。如果你的托管应用需要服务发现或跑批量任务，这两个是可以放心纳入架构的"免费搭子"。

十、省钱 5 招

1. App Runner 用完就暂停。开发和测试环境没有真实用户时，pause-service 一按，运行费归零，第二天 resume-service 即可。这是 App Runner 上回报最高的一个动作。
2. 给 App Runner 设活动实例上限。它就是官方的预算刹车，防止一次流量异常把账单顶穿；同时把并发数调高（在单机能扛的前提下），可以让更多请求挤进更少的实例。
3. Beanstalk 底层实例用 Spot 或预留实例。Beanstalk 的底层就是普通 EC2，Spotted 配置能省一大截；官方明确 Cluster 模式下 EC2 的折扣照常生效（但 EKS Auto Mode 的管理费不打折）。
4. 能用 Cluster 模式就用 Cluster。当你有多个容器化应用时，共享节点的装箱效率（官方估算约 23%）往往能盖过 EKS Auto Mode 约 12% 的管理溢价。
5. 把静态资源交给 CloudFront，别让应用扛流量。无论 App Runner 还是 Beanstalk，应用的流量费和数据传出都可能成为账单主角；把图片、JS、CSS 前置到 CDN，既降本又提速。

十一、7 个常见大坑

1. 把长连接应用塞进 App Runner。App Runner 面向的是 HTTP 服务，如果你要跑 WebSocket 长连接或需要持久化本地文件系统的应用（如 CMS），应改用 Fargate + 编排器或 EC2。
2. 忘了 App Runner 的"自动部署费"。开了自动部署就是 $1/应用/月，哪怕当月一次都没发布。应用一多、又都开了自动部署，这笔固定费会悄悄累积。
3. 以为 App Runner 有按月免费额度。它的定价页没有 with AWS Free Tier 列，没有每月免费量，只能吃账号级的 2026 免费计划额度。
4. 没看区域就选 App Runner。只有 11 个区域、没有香港。用户在香港/华南却选了 App Runner，延迟体验会明显吃亏。
5. Beanstalk 用了 Cluster 模式却以为自己也在免费期内。免费额度只覆盖 Standard 模式，Cluster 明确不在免费范围。
6. Beanstalk 忘了"平台更新"成本。托管平台更新（managed platform updates）功能本身免费，但滚动更新期间临时多跑的 EC2 实例是要计费的，虽然金额小，但要在预期里。
7. 没有给账号设预算告警就上生产。无论是 App Runner 的活动实例上限，还是 Beanstalk 的 Auto Scaling，都可能因流量或配置错误而放大账单。先用 Billing 的预算与 50%/75%/90% 三档通知兜底，再上生产。

十二、常见问题 FAQ

Q: App Runner 和 Elastic Beanstalk 到底哪个更便宜？ A: 没有绝对答案，取决于形态。App Runner 起步更低（开发测试档官方算例约 $4.8/月），且用完暂停就归零；Beanstalk 起步约 $12/月（单实例），但平台本身不收平台费，底层 EC2 还能吃 Spot/预留折扣。低流量常驻服务 App Runner 更省，需要一队实例、需长期运行的传统应用 Beanstalk 更省。

Q: App Runner 支持自定义域名和 HTTPS 吗？ A: 支持。默认就自带 HTTPS 的 awsapprunner.com 域名，绑定自定义域名时用 ACM 证书（证书免费），并可用 associate-custom-domain 命令完成。

Q: Elastic Beanstalk 会不会哪天突然收费？ A: 官方口径是"Beanstalk 本身不额外收费"，你只为底层资源付费。即便未来调整，也都体现在底层资源价格上，而不是新增一个平台费。为稳妥，重要环境仍建议设预算告警。

Q: 我的应用需要访问 VPC 里的 RDS，App Runner 能做到吗？ A: 可以。创建服务时传入 VPC ID、子网和安全组即可，App Runner 会为每个子网创建网络接口（建议至少两个子网以保证高可用）。VPC 接入本身不额外收费，只按数据传出计费。

Q: 2026 年的 AWS 免费套餐还能白嫖吗？ A: 新账号可进入免费计划：最高 $200 额度（注册即得 $100，完成入门操作最多再得 $100），有效期 6 个月或额度耗尽先到者为准，额度需在开通后 12 个月内用完。把账号加入 AWS Organizations 或建立 Control Tower landing zone，会使额度立即失效并自动转付费计划，务必注意。

Q: 我已经用了 ECS/Fargate，还有必要看 App Runner 吗？ A: 看你是否愿意维护任务定义、服务、负载均衡这一整套编排。App Runner 的价值是"把这一整套压成一次配置"；如果你已经有成熟的 ECS 工作流，App Runner 更适合用来跑那些"临时起意的小服务"。

Q: Beanstalk 的 Standard 和 Cluster 怎么选？ A: 单应用或少量传统 Web 应用，选 Standard（简单、灵活、免费额度覆盖）；已有一套容器化应用矩阵、希望共享节点降本，选 Cluster。

Q: 这两个服务能一起用吗？ A: 可以，它们不互斥。常见组合是企业把新写的容器化 API 放 App Runner、把历史遗留的传统应用迁到 Beanstalk，再用 Cloud Map 做统一服务发现、用 Batch 跑离线任务。

十三、小结

把这篇的决策路径再压缩一次：

• 能装进容器、想彻底告别服务器运维 → App Runner；记住它的账单主角是"运行时长 × 实例数"，善用暂停和活动实例上限两个旋钮。
• 传统 Web 应用、要能登机器、要在中国香港低延迟落地 → Elastic Beanstalk；记住平台免费、只付底层资源，Standard 简单、Cluster 共享降本。
• 配套需求 → 服务发现找 Cloud Map（$0.10/资源/月 起），离线批处理找 Batch（同样不额外收费）。

托管服务的意义，从来不是"更便宜"，而是"把工程师从基础设施上解放出来"。选型时先把"能不能满足形态与区域"这两个硬约束卡住，再在两者之间比成本和心智——顺序反了，省下的钱往往会被返工吃掉。

⚠️ 文中价格为 2026 年 10 月采集的参考价，实际费用随区域和官方调价变动，请以 AWS 官网为准。

🚀 需要 AWS 国际版账号？通过 3.chengzicloud.cloud 获取最新注册教程与专属优惠，助你轻松上云。

相关阅读

• AWS Lightsail vs EC2：轻量应用与弹性计算怎么选
• AWS ECS + Fargate 无服务器容器实战
• AWS Lambda 无服务器 API 从 0 搭建
• AWS EKS Kubernetes 深度实战
• AWS CodePipeline + CodeBuild CI/CD 实战
• AWS Amplify 前端全栈托管部署

本文由 3.chengzicloud.cloud 提供，点击访问首页了解更多