夜雨聆风今日学习主题
日期：2026-07-03 主题：Elastic Beanstalk 与 App Runner：应用托管入门 学习重点：理解更低运维门槛的应用部署方式。 今日说明：继续不输出普通封面图；包含抖音图文素材和可直接发布的图文 PNG。 重要更新：AWS 官方文档显示，AWS App Runner 从 2026-03-31 起不再对新客户开放；已有客户可以继续正常使用。今天仍学习 App Runner 的产品定位，但新客户选型时不能把它当作默认可开通方案。
AWS 云学习教程
1. 今日学习目标
学完今天这篇，你应该能回答这些问题：
Elastic Beanstalk 是什么，它帮用户托管了哪些应用部署工作？ App Runner 是什么，它和源码、容器镜像部署有什么关系？ Elastic Beanstalk 的 Application、Application version、Environment、Platform 分别是什么？ Web server environment 和 Worker environment 有什么区别？ App Runner service、source code、source image、auto scaling、VPC connector 怎么理解？ Elastic Beanstalk、App Runner、ECS、EKS、Lambda 怎么做基本区分？ 为什么“低运维门槛”不等于“完全不用理解底层资源”？
前几天我们学了 ECS、EKS、ECR。它们更偏容器运行和镜像管理。
今天看两个更偏“应用托管”的服务：Elastic Beanstalk 和 App Runner。
它们的共同点是：减少用户直接管理底层基础设施的负担，让开发者更快把应用部署起来。
但要注意：截至 2026-07-03，App Runner 已不再对新客户开放。已有客户可以继续使用；新客户选型需要优先考虑 Elastic Beanstalk、ECS、EKS、Lambda、Lightsail 等其他方案。
2. 什么是“应用托管”
应用部署不只是把代码放到服务器上。
一个 Web 应用真正上线，通常要处理：
运行环境。 服务器或容器。 负载均衡。 健康检查。 自动扩缩容。 日志。 版本发布。 回滚。 HTTPS。 环境变量。 网络和安全组。
如果团队直接使用 EC2，需要自己处理很多细节。
应用托管服务的价值是：把一些重复性部署和运维工作封装起来。
你更关注：
我的代码是什么 运行时是什么 入口端口是什么 需要多少容量 如何发布新版本平台帮你处理更多底层资源编排。
3. Elastic Beanstalk 是什么
AWS Elastic Beanstalk 是 AWS 的应用托管服务。
AWS 官方文档说明，Elastic Beanstalk 可以把 Web 应用部署到 AWS Cloud 上的多种受支持平台。你负责构建和部署应用，Elastic Beanstalk 负责预置 EC2 实例、配置负载均衡、设置健康监控，并动态扩展环境。
简单理解：
开发者上传应用代码 -> Elastic Beanstalk 选择平台 -> 自动创建和管理 EC2 / ALB / Auto Scaling / Health -> 应用上线它不是完全隐藏底层资源。
Elastic Beanstalk 会帮你创建和编排底层 AWS 资源，但你仍然可以看到并配置很多资源，例如 EC2、Auto Scaling、Load Balancer、Security Group、CloudWatch 等。
4. Elastic Beanstalk 核心概念
学习 Elastic Beanstalk，先掌握 5 个词：
Application
Application 是 Elastic Beanstalk 中的应用逻辑容器。
它可以包含多个版本和多个环境。
例如：
my-web-appApplication version
Application version 是某次上传的应用代码版本。
AWS 官方文档说明，Elastic Beanstalk 会在你上传源代码时创建 application version。
例如：
v1 v2 release-20260703Environment
Environment 是真正运行应用的一组 AWS 资源。
例如：
dev environment staging environment prod environment一个 Application 可以有多个 Environment。
Platform
Platform 是应用运行的语言或技术栈。
AWS 官方文档说明，Elastic Beanstalk 提供多种平台，你根据平台设计 Web 应用，Elastic Beanstalk 会把代码部署到所选 platform version 创建的活动环境中。
常见平台包括：
Java。 .NET。 Node.js。 Python。 Ruby。 PHP。 Go。 Docker。
Configuration
Configuration 是环境配置，例如实例类型、扩缩容、环境变量、负载均衡、日志、健康检查等。
5. Elastic Beanstalk 的两类环境
Elastic Beanstalk 主要环境 tier 有两类。
Web server environment
用于处理 HTTP 请求的 Web 应用。
典型结构：
用户 -> Load Balancer -> Auto Scaling group -> EC2 instances -> Application适合：
网站。 Web API。 后台管理系统。 传统三层应用。
Worker environment
用于处理后台任务。
AWS 官方文档说明，如果应用有耗时操作或工作流，可以把这些任务交给 dedicated worker environment。Worker environment 通常通过 Amazon SQS 队列接收和处理任务。
典型结构：
Web app -> SQS queue -> Worker environment -> 后台处理任务适合：
图片处理。 邮件发送。 报表生成。 异步任务。 定时任务。
6. Elastic Beanstalk 帮你管什么
Elastic Beanstalk 可以帮你处理：
创建 EC2 实例。 配置 Auto Scaling。 配置 Load Balancer。 部署应用版本。 健康检查。 环境监控。 日志收集。 部署策略。 平台版本管理入口。
但你仍然需要理解：
VPC 和子网。 安全组。 实例类型。 负载均衡费用。 应用日志。 环境变量。 数据库连接。 平台版本升级。 依赖包和运行时版本。
Elastic Beanstalk 降低了部署门槛，但并不意味着不用理解 AWS 基础设施。
7. Elastic Beanstalk 的发布和版本
Elastic Beanstalk 支持通过 application version 管理发布。
常见流程：
上传新代码包 -> 生成 application version -> 部署到 environment -> 观察健康状态 -> 必要时回滚旧版本Elastic Beanstalk 也支持多种部署策略，例如一次性部署、滚动部署、滚动附加批次、不可变部署、流量拆分等。
新手先记住：
Application version = 代码版本 Environment = 运行环境 Deploy = 把某个版本发布到某个环境8. Elastic Beanstalk 的平台版本
Elastic Beanstalk 平台版本会更新。
AWS 官方文档说明，Elastic Beanstalk 会定期发布新的 platform versions，用于更新 Linux 和 Windows Server 平台。新 platform versions 会带来软件组件更新、新功能和配置选项。
这意味着：
平台版本需要维护。 运行时版本会有生命周期。 老平台可能需要升级。 升级前要测试应用兼容性。
Elastic Beanstalk 不是“部署一次永远不管”。它减少基础设施创建和编排，但平台版本治理仍然重要。
9. App Runner 是什么
AWS App Runner 是一个更高抽象的应用托管服务。
AWS 官方文档说明，App Runner 可以从源代码或容器镜像直接部署到可扩展、安全的 Web 应用，不需要用户学习新技术、决定使用哪个计算服务，或知道如何预置和配置 AWS 资源。
简单理解：
源码或镜像 -> App Runner -> 自动构建 / 部署 / 运行 / 扩缩容 / 负载均衡它的目标是让 Web 应用和 API 更快上线。
但必须注意：AWS 官方 API 文档和 App Runner glossary 页面都显示，App Runner 从 2026-03-31 起不再对新客户开放。已有客户可以继续正常使用。
所以对新客户来说，App Runner 只能作为知识了解或已有客户维护场景，不应作为默认推荐的新开通服务。
10. App Runner 的两类来源
App Runner 支持两类 service source。
Source code
从源代码仓库部署。
App Runner 可以根据源代码构建应用，并部署到 App Runner service。
适合：
直接从代码仓库发布。 想减少 Dockerfile 和容器运行层管理。 简单 Web API。
Source image
从容器镜像部署。
例如镜像来自 ECR。
适合：
已经容器化的应用。 有现成镜像构建流程。 希望以容器镜像作为发布制品。
AWS 官方文档说明，不管 source type 是 source code 还是 source image，App Runner 都会负责启动、运行、扩展和负载均衡服务。
11. App Runner Service
App Runner 的核心对象是 service。
一个 service 包含：
来源：代码或镜像。 构建配置。 运行配置。 端口。 CPU 和 memory。 自动扩缩容配置。 环境变量。 网络配置。 日志和部署状态。
常见链路：
GitHub / ECR -> App Runner service -> 可访问的 Web service endpointApp Runner 会自动把应用跑起来，并处理负载均衡和扩缩容。
12. App Runner 的自动部署
App Runner 可以跟踪源代码或镜像变化。
AWS 官方文档说明，App Runner 的 CI/CD 能力可以跟踪 source image 或 code 的变化；当发现变化时，会自动构建并部署新版本到 App Runner service。
这对小团队很友好：
提交代码 -> App Runner 构建 -> 自动部署 -> 服务更新或者：
新镜像推到 ECR -> App Runner 检测变化 -> 自动部署新镜像13. App Runner 和 VPC
默认情况下，App Runner 更偏托管 Web 服务入口。
如果 App Runner service 需要访问 VPC 内资源，可以使用 VPC Connector。
AWS 官方文档说明，创建 VPC Connector 时需要指定 VPC、一个或多个 subnet，并可选指定 security groups。配置后可以把 VPC Connector 用于一个或多个 App Runner services。
典型场景：
App Runner service -> VPC Connector -> private subnet -> RDS / ElastiCache / internal service注意：VPC Connector 主要用于出站访问 VPC 资源。私有入站访问还涉及 VPC Ingress Connection 和 PrivateLink 相关能力。
14. Elastic Beanstalk 和 App Runner 的区别
两者都降低应用部署门槛，但抽象层不同。
Elastic Beanstalk
更像是把 EC2、Auto Scaling、Load Balancer 等资源封装起来。
特点：
底层资源更可见。 支持多种平台。 支持 Web server 和 Worker environment。 可配置项较多。 适合传统 Web 应用迁移到 AWS。 仍需要理解 EC2、ALB、Auto Scaling、VPC。
App Runner
更像是“给源码或镜像一个更高层的 Web 服务托管入口”。
特点：
更少配置。 直接从源码或镜像部署。 自动构建、运行、扩缩容和负载均衡。 更适合简单 Web 服务和 API。 但截至 2026-07-03，新客户不能再开通使用。
简单记忆：
Elastic Beanstalk：低门槛，但仍能看到底层 AWS 资源 App Runner：更高抽象，但当前只适合已有客户继续使用15. 和 ECS / EKS / Lambda 怎么区分
Elastic Beanstalk
适合想快速部署传统 Web 应用，同时还需要一定 EC2 / ALB / Auto Scaling 可配置性的场景。
App Runner
适合已有 App Runner 客户维护简单 Web service / API，或者学习其产品思路。新客户不能默认选择。
ECS
适合容器化应用，需要更明确的容器编排、服务副本、任务定义和部署控制。
EKS
适合需要 Kubernetes API、Helm、Operator、CRD、多集群治理的团队。
Lambda
适合事件驱动、短任务、无需长期运行服务的场景。
简单判断：
传统 Web 应用快速上 AWS：Elastic Beanstalk 已有 App Runner 客户的简单 Web 服务：App Runner 普通容器服务：ECS Kubernetes 生态：EKS 事件驱动函数：Lambda16. 低运维门槛不等于没有运维
很多用户容易误解“托管应用服务”。
低运维门槛的意思是：平台帮你减少一部分重复基础设施工作。
但仍然要关注：
应用运行时版本。 环境变量和密钥。 日志和错误排查。 健康检查。 数据库连接。 网络访问。 安全组和 IAM。 成本。 版本发布和回滚。 平台限制。
越高抽象的服务，越容易开始；但遇到复杂场景时，可控性可能更有限。
17. 成本从哪里来
Elastic Beanstalk 成本
Elastic Beanstalk 服务本身不额外收费，但它创建的 AWS 资源会收费。
常见成本包括：
EC2。 Load Balancer。 Auto Scaling 中的实例。 EBS。 RDS。 NAT Gateway。 CloudWatch Logs。 数据传输。
所以看 Elastic Beanstalk 成本，要看它背后创建了哪些资源。
App Runner 成本
App Runner 成本通常和 provisioned compute、请求处理、自动扩缩容、构建部署、网络流量等相关，具体以 AWS 官方价格页和账单为准。
对已有客户而言，需要关注：
服务是否长期运行。 CPU / memory 配置。 是否自动扩缩容。 是否访问 VPC。 日志和数据传输。
18. 常见误区
误区 1：Elastic Beanstalk 是过时服务，完全不能用
不准确。Elastic Beanstalk 仍适合一些传统 Web 应用快速部署和迁移场景。关键是看客户是否接受它的抽象和平台版本维护方式。
误区 2：Elastic Beanstalk 不需要懂 EC2
不准确。Elastic Beanstalk 会创建 EC2、ALB、Auto Scaling 等资源。排障和成本分析时仍要理解这些底层服务。
误区 3：App Runner 可以继续推荐给所有新客户
不准确。AWS 官方文档显示，App Runner 从 2026-03-31 起不再对新客户开放。已有客户可以继续使用。
误区 4：越高抽象越一定更好
不一定。高抽象降低上手门槛，但复杂网络、特殊部署、深度控制需求可能更适合 ECS、EKS 或更底层方案。
误区 5：托管应用服务不用做版本治理
不准确。应用版本、平台版本、运行时版本都要管理。
19. 新手看应用托管架构的顺序
建议按这个顺序看：
应用来源：源码包、代码仓库、容器镜像？ 运行方式：语言平台、Docker、Web service、worker？ 入口：公网 HTTP、内部服务、队列任务？ 底层资源：EC2/ALB 还是更高抽象服务？ 扩缩容：按实例、请求量、并发还是 CPU？ 网络：是否需要访问 VPC 内数据库？ 发布：版本如何部署和回滚？ 监控：日志和健康状态在哪里看？ 成本：背后实际创建了哪些资源？ 限制：服务当前是否对新客户开放、区域是否支持、运行时是否仍受支持？
20. 今日架构示例
Elastic Beanstalk Web 应用：
用户 -> Route 53 -> Load Balancer -> Elastic Beanstalk environment -> Auto Scaling group -> EC2 instances -> Application -> RDS / ElastiCache / S3Elastic Beanstalk Worker 应用：
Web application -> SQS queue -> Worker environment -> Background processingApp Runner 已有客户 Web 服务：
Source code / ECR image -> App Runner service -> Auto build / deploy / scale / load balance -> optional VPC Connector -> VPC resources21. 学习检查题
你可以用这些问题检查今天是否学明白：
Elastic Beanstalk 和直接使用 EC2 有什么区别？ Application、Application version、Environment 分别是什么？ Web server environment 和 Worker environment 有什么区别？ Elastic Beanstalk 背后常见会创建哪些 AWS 资源？ App Runner 可以从哪两类 source 部署？ App Runner 当前对新客户的开放状态是什么？ VPC Connector 解决 App Runner 的什么问题？ Elastic Beanstalk、ECS、EKS、Lambda 怎么做基本区分？ 为什么低运维门槛不等于不用看日志、网络、版本和成本？
22. 业务理解提示
客户问 Elastic Beanstalk 或 App Runner 时，通常真正关心的是：
能不能更快把应用部署到 AWS。 是否需要自己管理服务器。 原有 Web 应用迁移成本有多高。 团队有没有容器和 Kubernetes 能力。 是否需要访问 VPC 内数据库。 应用发布和回滚是否容易。 平台限制和服务开放状态是否影响选型。
作为销售人员，理解今天内容的关键是：不要只说“这个服务省运维”。要能判断客户应用是传统 Web、容器服务、Kubernetes 应用还是事件函数，再匹配对应的托管方式。尤其要记住 App Runner 当前不再对新客户开放这一点。
