MWAA Serverless added PythonOperator on 18 August 2026: 250 MB cap, 60-minute ceiling, no internet

Summary. On 18 August 2026 AWS added PythonOperator and BashOperator to Amazon MWAA Serverless, so the service can now run your own Python callables and shell scripts instead of only AWS-integration operators. The announcement does not mention the caps that decide whether a real DAG can move: a 250 MB limit on any single code file and on the uncompressed size of a zip archive, 75 GB of total code storage per account, a 60-minute maximum task execution timeout, a fixed worker of 1 vCPU and 3 GiB, Python 3.12 only, and tasks that run with no internet access by default. Pre-installed packages also override anything you bundle, so a workflow that ships boto3 1.44 will silently run the pre-installed boto3 1.43.1 instead. The prize for fitting inside those caps is real: AWS's worked example prices 2,000 short MWAA Serverless tasks at $4.00 for the month, against $449.11 to $1,047.46 for the always-on provisioned MWAA environments on the same pricing page, checked 22 August 2026. And AWS's own service overview page still tells you to choose provisioned MWAA "when you need custom Python operators or complex DAG logic" — advice the launch partly invalidated and partly did not, in a way worth being precise about.

What actually changed on 18 August 2026

Amazon MWAA Serverless is the pay-per-use deployment option for Amazon Managed Workflows for Apache Airflow. It runs Apache Airflow v3 with Python 3.12, takes YAML workflow definitions in the DAG factory format rather than Python DAG files, and gives every workflow its own IAM execution role. Until this launch, the supported operators list was roughly 130 AWS-integration operators and sensors — Athena, EMR, EMR Serverless, Glue, Glue Data Quality, Redshift, Batch, Step Functions, EventBridge, SNS, SQS, S3, S3 Tables, S3 Vectors, SageMaker and others. Useful for orchestrating AWS services. Useless for the two things data teams do constantly: run a Python function, run a shell script.

The 18 August announcement closed that gap. Both operators come from the Apache Airflow standard provider package, and MWAA Serverless accepts either import path: airflow.providers.standard.operators.python.PythonOperator (the Airflow 3 form) or the older airflow.operators.python.PythonOperator. Same for BashOperator. PythonOperator requires a python_callable parameter; BashOperator requires bash_command.

The mechanism is the genuinely new part. Your code is no longer part of your DAG. The YAML definition goes to Amazon S3 and is referenced by DefinitionS3Location; your Python modules and shell scripts go to S3 separately and are referenced by a new Code parameter carrying an S3Location structure with Bucket, ObjectKey and an optional VersionId. Each create or update captures definition and code together as one immutable workflow version. Omit VersionId and you pin to whatever object version exists at create time; include it and you pin to an exact S3 object version, which only exists if bucket versioning is on.

aws mwaa-serverless create-workflow \
    --name my-workflow \
    --definition-s3-location '{"Bucket": "DOC-EXAMPLE-BUCKET", "ObjectKey": "dags/my_dag.yaml"}' \
    --code '{"S3Location": {"Bucket": "DOC-EXAMPLE-BUCKET", "ObjectKey": "code/my_package.zip"}}' \
    --role-arn arn:aws:iam::111122223333:role/MyMWAAServerlessRole \
    --region us-east-1

The eight limits that decide whether you can move

AWS's quotas page and the Python and Bash operators guide between them carry the numbers that matter. None of them appear in the launch post.

Constraint	MWAA Serverless	What it rules out
Task execution timeout	60 minutes maximum	Any single long-running backfill, model training step, or full-table reload
Worker size	1 vCPU, 3 GiB, Linux x86_64	In-process pandas or Polars transforms over datasets that need more than ~3 GiB
Code package size	250 MB per file; 250 MB uncompressed zip	Bundling large ML wheels such as full PyTorch or CUDA builds
Total code storage	75 GB per account	Hundreds of independently packaged workflows with fat dependency trees
Concurrency	100 concurrent runs per account, 20 per workflow	Fan-out patterns that spawn hundreds of parallel tasks
Workflows	100 per account, 50 versions per workflow	Large multi-team estates without quota increases
DAG definition size	50 KB	Generated DAGs with very large static task lists
XCom payload	100 KB	Passing dataframes or large JSON between tasks

The 60-minute ceiling is the one that reshapes designs. Provisioned MWAA workers will happily run a task for hours. On MWAA Serverless a task that exceeds 60 minutes ends in TIMEOUT, which appears in the RunState field of get-workflow-run alongside STARTING, QUEUED, RUNNING, SUCCESS, FAILED, STOPPING and STOPPED. If your Python task today is a two-hour transform, the migration is not a lift-and-shift — it is a decomposition, or a handoff to AWS Batch or EMR Serverless through the operators that were already supported. The real cost here is usually the redesign, not the code.

The trap that will bite first: pre-installed packages win

The execution environment ships a fixed set of Python packages, and AWS is explicit that they take precedence over the same package bundled in your code:

Package	Pre-installed version
apache-airflow	3.0.6
apache-airflow-providers-amazon	9.32.0
boto3	1.43.1
botocore	1.43.1
dag-factory	1.0.0
lz4	4.4.4
aws-encryption-sdk	4.0.3 or later

Bundle a different version of any of these and your version is not used. The pre-installed one is imported instead. There is no error and no warning — the behaviour just quietly differs from your local test run. Teams pinning boto3 to pick up a new API shape are the obvious casualty, because the failure surfaces as an unexpected AttributeError or a missing parameter deep inside a task, not as a package resolution error at deploy time.

The zip layout is the second trap. Every source file and every dependency package must sit at the root of the archive, not in a subdirectory, and __pycache__ must be excluded because bytecode compiled on a different OS or architecture may not load. Dependencies must be built for Linux x86_64 and Python 3.12, which means the pip invocation is not the one most teams have in their build script:

pip install -r requirements.txt --target my_package \
    --platform manylinux2014_x86_64 \
    --python-version 3.12 \
    --only-binary=:all:

Without those flags pip installs wheels for your laptop and the imports fail at run time, inside the task, minutes after the deploy looked fine. Accepted upload formats are a single .py, a single .sh, or a .zip; single files go up unzipped. Code is extracted to /usr/local/airflow/dags in the worker, which is the Airflow DAGs directory, so root-level modules import directly, and BashOperator scripts run with that path as their working directory.

No internet by default

Tasks run without internet access unless you attach a VPC with internet access through the NetworkConfiguration parameter. This is the single most common reason a freshly migrated PythonOperator will hang and then fail: any call to a third-party API, any runtime pip install, any webhook, any external SaaS endpoint gets nothing. AWS service calls work, because the workflow execution role's credentials are resolved automatically by the default credential provider chain and the pre-installed boto3 1.43.1 talks to AWS endpoints.

If you do need egress, the networking guide sets out the requirements for public routing: up to five security groups, all in the same VPC, each with a self-referencing inbound rule and an outbound rule for all traffic (0.0.0.0/0, or ::/0 for IPv6). MWAA Serverless supports a customer-owned VPC, a service-owned shared VPC, and subnets shared from another account through AWS RAM. A VPC remains optional — until your code needs the internet, at which point it is not.

Where AWS's own documentation now contradicts itself

Three inconsistencies are live as of 22 August 2026, and each one can send a team down the wrong path.

First, the service overview page still lists "Custom Python operators or complex DAG logic" as a reason to choose provisioned MWAA over Serverless, and its comparison table still describes the Serverless workflow definition as "YAML workflows definitions using the DAG factory format, supporting AWS operators" while giving provisioned MWAA "Python DAG support with AWS and custom operators". Read literally, that page tells you this launch did not happen.

The precision matters, though, because the overview page is not entirely wrong. "Custom Python operators" in Airflow means subclassing BaseOperator to define your own operator type. That is still not supported. What shipped on 18 August is the ability to run custom Python callables and shell commands through the two standard operators. If your DAGs call PythonOperator(python_callable=my_func), you can move. If your DAGs import a home-grown MyCompanySnowflakeOperator, you cannot, and the overview page's advice still stands for you.

Second, the two size limits are stated with different scopes. The Python and Bash operators guide says "Total code storage across all workflows in your account: 75 GB", which reads as account-wide. The quotas page lists "Maximum code storage per account | 75 GB" under a heading that opens with "Unless noted otherwise, each quota is Region-specific". One of those readings gives you 75 GB globally and the other gives you 75 GB in every Region. Check Service Quotas in your own account before you plan capacity on either reading.

Third, the MWAA pricing page has not caught up either. Its only MWAA Serverless worked example covers workflows that "use AWS Managed Operators", prices 50 hours of AWS Managed Tasks usage at $0.080 per hour for a total of $4.00, and then labels that rate "price per hour for a large environment" — a phrase that makes no sense for a service with no environments. There is no separately stated rate on that page for tasks that run PythonOperator or BashOperator. The billing rule itself is clear enough: you pay per task for its duration, billed at one-second resolution, with a one-minute minimum and no upfront commitment.

For scale, the same page's provisioned MWAA examples put a large environment at $0.99 per hour, or $736.56 for a 31-day month, reaching $1,047.46 once nine additional large workers at $0.22 per hour, one additional scheduler at $0.22 per hour, two additional web servers at $0.11 per hour and 40 GB of meta database storage at $0.10 per GB-month are added. A small environment example lands at $449.11 per month. That gap between roughly $449 to $1,047 a month of always-on infrastructure and $4.00 for 2,000 short tasks is the entire argument for MWAA Serverless — and it only holds for workloads that fit inside the eight limits above.

How to tell whether this is you

Run three checks against your existing DAGs before you plan anything.

Count the tasks that run longer than 60 minutes. Anything over the line needs decomposition or a handoff to Batch, EMR Serverless or Glue, all of which have supported operators. Then check peak memory: a fixed 1 vCPU and 3 GiB worker will not carry an in-process transform that currently runs on a large provisioned worker. Then grep your imports for anything in the pre-installed table at a different pin, because those are the failures that will not announce themselves.

If those clear, the conversion path is mechanical. AWS ships a converter, installed with pip install python-to-yaml-dag-converter-mwaa-serverless and run as dag-converter convert source.py --output /output_yaml/destination, which emits a <dag_id>.yml per DAG. One Python DAG file can produce several YAML workflows, so the output count will not always match the input count. There is still no Airflow UI on MWAA Serverless — monitoring runs through CloudWatch Logs and get-workflow-run, and logs can take a few minutes to appear after a run starts.

India-specific considerations

The no-internet default matters more for Indian teams than the docs imply, because a large share of pipelines here call domestic third-party endpoints — payment gateways, GSTN, Aadhaar-adjacent KYC vendors, logistics APIs. Every one of those needs a VPC with egress and the security group rules above, which pulls a networking change into what looked like an orchestration change. Where those pipelines move personal data, the workflow-per-execution-role isolation model is easier to defend under the Digital Personal Data Protection Act 2023 than a single provisioned MWAA environment where every DAG shares one execution context, because you can scope each workflow's role to exactly the S3 prefixes and tables it touches. Design applications aligned with DPDP requirements from the workflow definition upward, not as a later retrofit.

What is still unknown

AWS has not published a per-task rate specific to PythonOperator and BashOperator tasks on the pricing page, only the AWS Managed Tasks example. The 75 GB scope question is unresolved in the documentation. And there is no stated path for custom BaseOperator subclasses, which remains the clearest reason to stay on provisioned MWAA. Teams weighing the same pay-per-use versus always-on question elsewhere in the AWS data stack will recognise the shape of it from the AWS Glue 6.0 price reduction and from Redshift's long-term system table retention on S3 Tables; the same trade-off drives the choice between Lambda durable execution and Step Functions. The wider cost picture sits in our guide to cloud FinOps for Indian teams.

FAQ

What did AWS add to MWAA Serverless on 18 August 2026?

AWS added support for PythonOperator and BashOperator from the Apache Airflow standard provider package. Workflows can now run custom Python callables and shell scripts as tasks. Code is uploaded to Amazon S3 separately from the YAML workflow definition and referenced through a new Code parameter when creating or updating a workflow.

How large can an MWAA Serverless code package be?

A single code file may reach 250 MB, and a zip archive may reach 250 MB uncompressed. Total code storage is documented as 75 GB per account. Accepted formats are one .py file, one .sh file, or a .zip archive with every source file and dependency placed at the archive root.

What is the maximum task execution time on MWAA Serverless?

The documented maximum task execution timeout is 60 minutes. A task that exceeds it ends with a TIMEOUT run state. Workloads that currently run longer on provisioned MWAA workers must be decomposed into shorter tasks or handed to AWS Batch, EMR Serverless or Glue through their existing supported operators.

Can MWAA Serverless tasks reach the internet?

Not by default. Tasks run without internet access unless you supply an Amazon VPC with internet access through the NetworkConfiguration parameter. Public routing requires up to five security groups in one VPC, each with a self-referencing inbound rule and an outbound rule allowing all traffic on 0.0.0.0/0 or ::/0.

Why is my bundled boto3 version being ignored?

Pre-installed packages take precedence over the same package bundled inside a code package. The environment ships boto3 1.43.1, botocore 1.43.1, apache-airflow 3.0.6, apache-airflow-providers-amazon 9.32.0 and dag-factory 1.0.0. Bundling a different version of any of these has no effect and produces no warning.

Does this launch mean custom Airflow operators now work?

No. The launch covers two standard-provider operators that run your Python callables and shell commands. Writing your own operator class by subclassing BaseOperator is still unsupported, which is why the AWS service overview page continues to recommend provisioned MWAA for teams that depend on home-grown operator types.

How is MWAA Serverless billed compared with provisioned MWAA?

MWAA Serverless charges per task for its duration, billed at one-second resolution with a one-minute minimum. AWS's worked example prices 50 hours of AWS Managed Tasks usage at $0.080 per hour, totalling $4.00. Provisioned MWAA examples on the same page run from $449.11 to $1,047.46 per month.

What resources does an MWAA Serverless worker get?

Each task runs on an Apache Airflow worker with 1 vCPU, 3 GiB of memory, Linux x86_64 and Python 3.12. That size is fixed and not configurable. Code is extracted to /usr/local/airflow/dags, which is also the working directory for BashOperator scripts and the import root for Python modules.

How eCorpIT can help

eCorpIT's data engineering services team migrates Apache Airflow estates between provisioned and serverless deployment models, including the DAG decomposition that a 60-minute task ceiling forces and the dependency repackaging that a root-level 250 MB zip requires. We are CMMI Level 5 and ISO 27001:2022 certified, and we design pipelines aligned with DPDP Act 2023 requirements. If you are weighing an MWAA Serverless move against a provisioned environment, contact us with your DAG inventory and we will tell you which workflows fit inside the current limits.

References

1. Amazon MWAA Serverless now supports PythonOperator and BashOperator, AWS What's New, 18 August 2026
2. Using Python and Bash operators, Amazon MWAA Serverless User Guide
3. Supported operators, Amazon MWAA Serverless User Guide
4. What is Amazon MWAA Serverless?, Amazon MWAA Serverless User Guide
5. Quotas for Amazon MWAA Serverless, Amazon MWAA Serverless User Guide
6. Key concepts, Amazon MWAA Serverless User Guide
7. Networking, Amazon MWAA Serverless User Guide
8. Convert Python DAG to YAML definition, Amazon MWAA Serverless User Guide
9. Create an Amazon S3 bucket for Amazon MWAA Serverless, Amazon MWAA Serverless User Guide
10. Amazon Managed Workflows for Apache Airflow pricing, AWS
11. PythonOperator, Apache Airflow standard provider documentation
12. AWS What's New recent announcements feed

Last updated: 22 August 2026.