2026 亚马逊 MWAA 深度实战：托管 Apache Airflow 两种模式怎么选，micro 到 2xlarge 六档真实价格、Airflow 3.x 支持矩阵与 CLI 建环境全流程

Meta Description: 2026 AWS MWAA（托管 Apache Airflow）深度实战：Serverless 与托管环境怎么选、micro 到 2xlarge 六档逐小时价格、Airflow 3.3.1 支持口径、31 个区域与配额，附 CLI 建环境全流程与账单估算。

30 秒结论：Amazon MWAA（Amazon Managed Workflows for Apache Airflow）是 AWS 把开源 Apache Airflow 直接托管起来的服务——你只写 DAG，AWS 负责调度器、Worker、Web UI、元数据库、打补丁与自动扩缩容。2026 年它有两个部署模式：托管环境（Provisioned，mw1 系列） 按"环境·小时"常驻计费，最低档 micro 为 $0.29/小时，最常用的 small 为 $0.49/小时、large 为 $0.99/小时；MWAA Serverless 则按 AWS Managed Task 的时长计费、每秒计费、最低 1 分钟，没有环境常驻费用（us-east-1 参考价 $0.080/小时）。最关键的一条：MWAA 不在 AWS 免费套餐范围内，环境一旦创建就按小时计费——哪怕你一个任务都没跑,一个 small 环境满月（744 小时）仅环境费就约 $364.56。所以决定账单的往往不是任务量，而是环境规格与常驻时长。

决策口诀：跑数据管道、要 Airflow 生态与可移植性 → MWAA；秒级事件驱动编排、按状态转换计费 → Step Functions；真正要跑 Spark/ETL 计算 → Glue + EMR（MWAA 只编排、不做计算）；只想"每天定时跑个脚本" → EventBridge Scheduler。

关键词：Amazon MWAA、Apache Airflow 托管、MWAA 价格、MWAA Serverless、mw1.small、mw1.large、AWS 工作流编排、DAG、AWS 国际版、AWS 免费套餐

一、先划边界：MWAA ≠ Step Functions ≠ Glue ≠ 自建 Airflow

AWS 上"编排"相关的产品名字高度相似，最容易买错。先用一张表把边界钉死：

一句话记忆：编排用 MWAA，事件用 Step Functions，计算用 Glue/EMR，实时用 Kinesis。 MWAA 官方 FAQ 也给了同样的口径——若你重视开源与可移植性选 MWAA，若你重视成本与性能（如流式数据处理）选 Step Functions。

二、两种部署模式：托管环境 vs MWAA Serverless

2026 年 MWAA 最大的变化是多了一条 Serverless 路线。两者的计费逻辑完全不同，选错模式比选错规格更贵：

一句判断法：如果你的 Airflow 一天里大部分时间在"等待触发"而不是"在跑任务"，先算一遍 Serverless 的钱；如果它 7×24 有活干，托管环境更可控。

三、逐档真实价格（us-east-1，2026-10 采集）

下表是美国东部（弗吉尼亚北部）的官方单价，采集自 AWS MWAA 定价页与 AWS Price List API（AmazonMWAA，us-east-1）。注意它是一个"环境费 + 三份实例费 + 存储费"的组合：

另外两项固定费用：

⚠️ 两点最容易踩坑：第一，micro 档没有独立的 Worker/Scheduler/Web Server 报价，它是固定规格、不能像大规格那样单独加 Worker；第二，环境基础费是"开机就付"，含 2 Scheduler + 2 Web Server + 1 Worker，超出部分才按上表加价。价格随区域与官方调整变动，请以 AWS 官网为准。

四、账单怎么估：三个官方算例复算

MWAA 定价页给了三个算例，我把它复算成表格，你对着套自己的场景即可（均为 31 天/月）：

这组数字把 MWAA 的成本结构暴露得很清楚：

• 环境费是绝对大头。 small 场景里 $364.56 占了总账单的 81%，它是 744 小时 × $0.49，与你跑不跑任务无关。
• Worker 费比想象中便宜。 50 个并发 Worker 只多花 $83.55，因为你只为"额外的 49 个"付钱，且只在真正并发的那些小时付。
• Scheduler 常驻也不便宜。 large 场景里 3 个 Scheduler 中有 1 个是额外的，但它 7×24 常驻 → 744 小时 × $0.22 = $163.68，比 Worker 还贵。
• Serverless 对低频负载是降维打击。 同样量级的任务若走 Serverless，可能只有几美元；但一旦任务变成 7×24 常态，Serverless 的按秒单价会反超托管环境。

五、Airflow 版本支持矩阵与升降级规则

MWAA 的版本策略是很多团队选型时的隐形约束。截至 2026-10-19，支持的版本与上游发布/MWAA 上线时间如下：

三条必须知道的规则：

1. 只能升/降"小版本"，不能跨大版本。 官方原文口径：你可以从 x.1.z 升到 x.2.z，但不能从 1.y.z 升到 2.y.z；降级同理，只能降到仍在支持的更早小版本。想上 Airflow 3.x 且环境还在 2.x，需要走 MWAA 迁移指南（含元数据库备份），不是点一下"升级"就行。
2. 废弃版本已于 2025-12-30 停止支持。 v2.4.3、v2.5.1、v2.6.3 三个版本从该日起 EOS：不能再用来建新环境、不能升降级到这些版本、也不再提供技术支持（已有环境可继续跑，但风险自负）。
3. 承诺：同时至少支持 3 个小版本、每个版本至少 12 个月，并提前 180 天通过 Health Dashboard 通知 EOS。这意味着你的版本不会"突然消失"，但你必须自己负责把它保持在支持范围内。

一个实操细节：从 v2.7.2 起，requirements.txt 必须包含 --constraint 语句。如果你不写，MWAA 会替你补一个约束文件以保证依赖与 Airflow 版本兼容——但显式写上更可控，尤其是你要锁定 Provider 包版本时。

六、区域覆盖与配额

MWAA 目前在全球 31 个区域可用（不含中国区，中国区需另走 cn-north 的独立账号体系）。区域分布大致如下：

服务配额（默认值，多数可申请提升）：

规划时记住两点：大规格环境（xlarge/2xlarge）默认只能建 5 个，做多环境隔离的团队要提前报提额；Worker 默认上限 25、Web Server 上限 5，如果你的 DAG 峰值并发会超过 25，靠加 Worker 解决不了，得改用"多环境分片 + 上游限流"。

七、实操：用 CLI 从 0 建一个 MWAA 环境

下面是最小可用的建环境流程。它会创建 S3 桶（放 DAG）→ VPC 与私有子网 → IAM 执行角色 → MWAA 环境，最后拿到访问凭据。

第 1 步：建 S3 桶并上传 DAG 与依赖。

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
BUCKET="mwaa-dags-${ACCOUNT}-us-east-1"
aws s3 mb "s3://${BUCKET}" --region us-east-1

aws s3 cp dags/ "s3://${BUCKET}/dags/" --recursive
aws s3 cp requirements.txt "s3://${BUCKET}/requirements.txt"

第 2 步：准备 VPC 与私有子网。 MWAA 的 Scheduler 与 Worker 跑在 Fargate 容器里，必须能访问私有子网中的 VPC endpoint。最小做法是借用默认 VPC 的两个私有子网，并放通出网（NAT 或 VPC Endpoint）：

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query "Vpcs[0].VpcId" --output text)
SUBNETS=$(aws ec2 describe-subnets --filters "Name=vpc-id,Values=${VPC_ID}" \
  --query "Subnets[0:2].SubnetId" --output text | tr '\t' ',')
echo "VPC=${VPC_ID} SUBNETS=${SUBNETS}"

第 3 步：创建执行角色。 这个角色会被 Airflow Worker 承担，用于访问 S3、Glue、Athena 等下游服务，所以最小权限原则很关键：

cat > mwaa-trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": ["airflow.amazonaws.com", "airflow-env.amazonaws.com"] },
      "Action": "sts:AssumeRole"
    }
  ]
}
JSON

ROLE_ARN=$(aws iam create-role --role-name mwaa-demo-role \
  --assume-role-policy-document file://mwaa-trust.json \
  --query "Role.Arn" --output text)
echo "ROLE_ARN=${ROLE_ARN}"
aws iam attach-role-policy --role-name mwaa-demo-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonMWAAFullConsoleAccess 2>/dev/null || true

第 4 步：创建 MWAA 环境。 下面用 mw1.small、Airflow 3.0.6，Worker 范围 1–10，Scheduler 数 2：

aws mwaa create-environment \
  --name demo-mwaa \
  --region us-east-1 \
  --airflow-version 3.0.6 \
  --environment-class mw1.small \
  --source-bucket-arn "arn:aws:s3:::${BUCKET}" \
  --dag-s3-path dags \
  --requirements-s3-path requirements.txt \
  --execution-role-arn "${ROLE_ARN}" \
  --network-configuration "SubnetIds=${SUBNETS},SecurityGroupIds=${SG_ID}" \
  --webserver-access-mode PUBLIC_ONLY \
  --min-workers 1 --max-workers 10 --schedulers 2

环境创建通常需要 20–30 分钟，期间可以用下面的命令轮询状态：

watch -n 30 "aws mwaa get-environment --name demo-mwaa \
  --query 'Environment.Status' --output text --region us-east-1"

第 5 步：拿到 Airflow UI 与 CLI 的访问凭据。 MWAA 不允许直接用 IAM 密码登录 Airflow UI，而是签发临时 token：

aws mwaa create-web-login-token --name demo-mwaa --region us-east-1 \
  --query "WebServerHostname" --output text

aws mwaa create-cli-token --name demo-mwaa --region us-east-1 \
  --query "CliToken" --output text

拿到 CliToken 后即可用官方脚本调用 Airflow 原生 CLI（如 airflow dags list、airflow tasks run）。生产环境建议把 webserver-access-mode 设为 PRIVATE_ONLY，配合 VPC 内访问与 IAM 策略，避免 Web UI 暴露到公网。

八、DAG 实战：S3 → Glue → Athena 的每日编排

建好环境后，把下面这个 DAG 放进 dags/ 目录并同步到 S3，MWAA 会自动加载：

from datetime import datetime, timedelta
from airflow import DAG
from airflow.providers.amazon.aws.operators.glue import GlueJobOperator
from airflow.providers.amazon.aws.operators.athena import AthenaOperator
from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor

with DAG(
    dag_id="daily_s3_glue_athena",
    start_date=datetime(2026, 10, 1),
    schedule="0 2 * * *",
    catchup=False,
    max_active_runs=1,
    default_args={"retries": 2, "retry_delay": timedelta(minutes=5)},
) as dag:
    wait_for_data = S3KeySensor(
        task_id="wait_for_data",
        bucket_name="my-raw-bucket",
        bucket_key="raw/{{ ds }}/events.parquet",
        poke_interval=60,
        timeout=3600,
    )

    run_glue = GlueJobOperator(
        task_id="run_glue",
        job_name="etl_daily",
        script_args={"--ds": "{{ ds }}"},
        wait_for_completion=True,
    )

    query_athena = AthenaOperator(
        task_id="query_athena",
        query="SELECT count(*) AS rows_today FROM analytics.daily_metrics",
        database="analytics",
        output_location="s3://my-athena-results/",
    )

    wait_for_data >> run_glue >> query_athena

这段 DAG 完整覆盖了 Airflow 的三个核心概念：Sensor（等数据）→ Operator（跑任务）→ 依赖（>>）。几个关键点：

• S3KeySensor 负责"等数据落地"，避免 Glue 在源文件还没到时就启动。poke_interval 与 timeout 决定等待节奏。
• GlueJobOperator 只是"触发并等待"，真正的计算在 Glue 上计费，MWAA 自身不产生这部分费用——这也再次印证了边界：MWAA 是编排层。
• schedule="0 2 *" 表示每天 02:00 触发；catchup=False 防止首次启用时把历史日期全部回补（这是新手最容易造成"一上线就烧掉一堆 Worker 小时"的坑）。

九、架构与安全：托管之后，你还要自己准备什么

MWAA 的"托管"边界很清晰：AWS 管 Airflow 的运行，你管网络、权限与依赖。理解这张归属表，是避免环境建成后 DAG 跑不起来的关键。

两种访问模式怎么选：Web Server 支持 Public network（VPC endpoint 可经互联网访问）与 Private network（VPC endpoint 只在你的 VPC 内可达），两者都由 IAM 访问控制策略与 AWS SSO 决定谁能登录。生产环境建议用 Private 模式，配合 VPC 内跳板机或 VPN 访问。

安全能力的差异：MWAA 两种模式都提供 VPC 隔离、端到端加密与细粒度访问控制；区别在于 Serverless 提供工作流级（workflow-level）控制，而托管环境提供环境级（environment-level）边界——如果你的不同业务线需要严格的数据隔离，就给它们各自开一个环境。另外，多 Scheduler 只在 Airflow v2 及以上支持。

Worker 舰队机制：MWAA 用容器按需扩缩 Worker 队列，以降低 Scheduler 中断风险；它既支持调用 Amazon ECS 容器上的任务，也支持用 Kubernetes Operator 在集群里创建并运行 Pod——这意味着 MWAA 可以统一编排 ECS 与 EKS 上的工作负载。

十、能编排哪些下游服务：Operator 与插件生态

选 MWAA 的核心理由之一是 Airflow 的开放可扩展性。官方明确支持与下列服务集成：

在此之上，MWAA 支持全部 100 多个 Airflow 社区插件，以及你自己开发的自定义插件——只要把插件包放进 S3 桶即可生效。日常最常用的 Operator / Sensor 大致是这些：

一条心法：Operator 只负责"触发与等待"，计算与存储费用记在下游服务的账上。MWAA 的账单只包含"编排"这一层的成本——所以"用 MWAA 编排 Glue"与"用 Glue 自己跑"相比，MWAA 只多出一层环境费，不会重复收取计算费。

十一、同一份负载，三种方案的月账单能差三个数量级

把"选型"落成钱最直观。假设一个中等规模的日常负载：每天触发 10 次任务、每次约 5 分钟，一个月按 30 天算：

同样是"每天跑 10 个小任务"，账单从 $0.05 到 $364.56——差了三个数量级。原因不是单价贵，而是计费对象根本不同：托管环境买的是"随时可用的常驻容量"，而 Step Functions 与 MWAA Serverless 买的是"实际执行的那几秒钟"。

那么 Serverless 与托管环境的临界点在哪里？ 用 small 环境的常驻费去除以 Serverless 单价即可估出：

• $364.56 ÷ $0.080 ≈ 4,557 任务小时/月
• 折合每天约 152 任务小时，约等于 6.3 个任务 24×7 不间断并发运行

换句话说，只有当你的并发任务长期稳定在 6 个以上时，small 托管环境才比 Serverless 更划算。低于这个量级，Serverless 几乎总是更便宜；一旦超过、而且 DAG 生态依赖复杂（需要自定义 Python 依赖、社区插件、精细调优 Scheduler 与 Worker），再切回托管环境。

结论：MWAA 本身不做计算，它的费用几乎全部是"编排层的固定成本"。所以在按下"创建环境"之前，先算清楚你的负载是常驻型还是脉冲型——这是决定账单的第一个开关，也是全文所有优化手段里最值钱的一条。

十二、成本优化与八个避坑点

1. 开发和测试用 mw1.micro。 环境费 $0.29/小时，比 small 便宜 41%，验证 DAG 逻辑完全够用。上生产前再切规格（注意：规格变更需要环境更新，会有一段时间不可用）。
2. 盯住"环境常驻费"，而不是任务量。 small 满月环境费约 $364.56 是硬成本。如果团队只在工作日白天用，考虑用 API 在非工作时间删除/重建环境（注意元数据库会重置）或用 Serverless。
3. 别把 min-workers 设太高。 默认 1 个 Worker 就够撑起大多数批处理；设成 5 意味着哪怕没任务也在为额外 4 个 Worker 付钱。
4. Scheduler 常驻费容易被忽略。 超过 2 个 Scheduler 后，每个 $0.22/小时 ≈ 满月 $163.68，加之前先确认调度延迟真的需要。
5. 元数据库会随 DAG 运行历史膨胀。 官方算例里"200 个每日 DAG × 20 个任务 × 保留 6 个月 ≈ 40 GB → $4/月"。定期清理历史 DAG Run 能把这笔钱压住。
6. requirements.txt 务必写 --constraint。 从 Airflow v2.7.2 起这是强要求，不写会让依赖兼容性失控；写死 Provider 版本可避免上线后 DAG import 失败。
7. 别把 MWAA 当秒级事件引擎。 Airflow 的调度粒度是分钟级，适合批处理；秒级、事件驱动的场景应交给 Step Functions（$0.000025/次状态转换，含每月 4,000 次免费额度）。
8. MWAA 不在 AWS 免费套餐内，没有免费额度。 这点和 Lambda、S3 等"有免费层"的服务完全不同——创建环境即开始计费。想先零成本体验 Airflow，可以用 EC2 免费层自建或本地 Docker 跑 Airflow，验证好了再迁到 MWAA。