AWS Big Data Blog
PythonOperator and BashOperator Now Available on Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Serverless
If you run Apache Airflow workflows on Amazon MWAA Serverless, you can now use PythonOperator and BashOperator to run custom code directly in the serverless runtime. Previously, Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Serverless only supported orchestration of AWS services through operators for scheduling tasks, managing dependencies, and handling retries. It did not support running your own Python functions or shell scripts natively. If you needed custom Python logic or shell commands, you had to wrap code in AWS Lambda functions, start Amazon Elastic Container Service (Amazon ECS) tasks, or use other AWS compute services. These alternatives add complexity, cost, and latency to your orchestration pipelines.
With this launch, you can run custom Python functions and shell scripts directly within the serverless task runtime, without requiring additional infrastructure. This means you can now use PythonOperator and BashOperator many data engineering teams rely on for ETL pipelines and data quality checks – without provisioning additional compute.
In this post, we walk through how this feature works and demonstrate a practical example: building a serverless pipeline that converts CSV files to JSON format using a PythonOperator, and verifies the output using a BashOperator. By the end, you will know how to:
- Package a Python module with dependencies and upload it to an Amazon Simple Storage Service (Amazon S3) bucket as a code bundle
- Define a multi-task workflow using the dag-factory compatible YAML
- Create and run a workflow with the AWS Command Line Interface (AWS CLI)
- Verify that your pipeline produced the expected output
How it works
With MWAA Serverless, you can package your custom code, upload it to an Amazon S3 bucket, and reference it when creating a workflow. The service snapshots your code at workflow creation time and uses that snapshot for all subsequent runs of the same workflow version.
Code bundles
A code bundle is the package that contains your custom logic. You package your Python modules or shell scripts and upload them to an Amazon S3 bucket. A code bundle can be:
- A single .py file or .sh bash script (uploaded to an Amazon S3 bucket)
- A ZIP archive containing multiple shell scripts, Python modules and dependencies (up to 250 MB)
Execution model
When you create or update a workflow, MWAA Serverless snapshots your code bundle from an Amazon S3 bucket provided and stores it on the service side. At task execution time, the service uses this snapshot – not the object currently residing in your Amazon S3 bucket – to run your code in an isolated runtime environment.
Python and Bash tasks do not have internet access. They can reach only Amazon S3, Amazon Elastic Container Registry (Amazon ECR), and Amazon CloudWatch, which are the services the runtime requires to operate. To have internet access, configure the workflow with Amazon VPC so that it can go through the provided VPC.
Supported operators
The following table describes the two operators now available in MWAA Serverless.
| Operator | Description |
| PythonOperator | Executes a Python callable (function) from your code bundle |
| BashOperator | Runs shell commands or scripts |
Security
AWS Key Management Service (AWS KMS) encrypts your code bundles at rest. IAM policies control who can create, update, and trigger the workflows. The execution role scopes what AWS resources your code can access at runtime.
Prerequisites
Before getting started, verify that you have the following resources and tools configured in your AWS account:
- An AWS account with access to Amazon MWAA Serverless
- AWS CLI v2 (latest version) installed and configured. To install or update, see Installing or updating to the latest version of the AWS CLI.
- An Amazon S3 bucket for storing DAG definitions and code bundles
- An IAM role that MWAA Serverless can assume (see the execution role setup below)
Walkthrough: Building a serverless CSV-to-JSON pipeline
In this walkthrough, we build a pipeline that converts CSV files to JSON format – a common data transformation for downstream APIs and analytics systems that consume JSON. The pipeline uses a PythonOperator for the conversion logic and a BashOperator to verify the output. Here is what the pipeline does:
- Reads a CSV file from an Amazon S3 bucket
- Converts it to JSON format with column type inference
- Writes the JSON file back to an Amazon S3 bucket
- Validates record counts match between source and output
Step 1: Create the execution role
Create an IAM role that your workflow assumes at runtime. The trust policy must allow the airflow-serverless.amazonaws.com service to assume the role:
Create the role and attach an inline policy granting least-privilege access to your S3 bucket:
Step 2: Write the Python module
Create a file called csv_to_json.py with the conversion logic:
This function uses boto3 (which comes pre-installed with the MWAA Serverless execution environment) and Python’s built-in csv and json modules. The conversion reads the CSV, infers numeric types, and writes a JSON lines file back to the S3 bucket.
Step 3: Write the verification script
Create a file called verify_output.sh. This script validates the pipeline output by comparing the record count in the source CSV against the output JSON file. If the counts do not match, the task fails with a non-zero exit code, which causes the workflow run to fail.
This script runs the AWS CLI, which is bundled as a dependency in the code package. The s3 cp streams the file content to stdout without writing to disk, allowing standard shell tools like wc -l and tail to process it. The execution role credentials are automatically available in the execution environment, so the CLI can access S3 without additional configuration.
Step 4: Package and upload the code to Amazon S3
Since the verification script uses the AWS CLI, bundle it as a dependency in the ZIP archive along with your Python module and shell script:
Upload a sample CSV file for testing:
Step 5: Define the DAG (YAML)
MWAA Serverless uses a declarative YAML format for DAG definitions. Create a file called conversion_dag.yaml:
This DAG defines two tasks:
convert_to_json– Runs the convert function from the Python module to transform CSV to JSON lines.verify_output– Runs a shell script that validates the pipeline output by comparing source and output record counts, failing the task if they do not match.
Upload the DAG definition to S3. Note: You can also run inline Bash commands directly without a shell script.
Step 6: Create the workflow
Create the MWAA Serverless workflow, referencing the DAG definition and the code bundle:
The response includes a WorkflowArn that you use to trigger runs:
Step 7: Run the workflow
Trigger a workflow run:
The response confirms the run has started:
Step 8: Monitor execution
Check the status of your run:
A successful run returns:
Step 9: Verify the output
Confirm the JSON file was written to the S3 bucket:
You should see the JSON file:
You can also verify task-level output in Amazon CloudWatch Logs. Open the log group for your workflow and find the convert_to_json task log stream:
Considerations and limits
When planning your workloads on MWAA Serverless with these operators, keep the following considerations in mind:
- Code bundle size – ZIP archives must be under 250 MB per bundle.
- Network access – Python and Bash tasks do not have internet access. They can reach a limited set of AWS services required for the runtime to function (Amazon S3, Amazon ECR, and Amazon CloudWatch) but cannot call other AWS services or external endpoints. If your workflow requires calls to external APIs, preprocess that data and store it in an Amazon S3 bucket before invoking the workflow.
- Runtime dependencies – boto3 and the Python standard library are pre-installed. For additional packages (such as pandas or requests), bundle them in your ZIP archive following the Amazon MWAA Serverless packaging guidelines.
- Execution timeout – Tasks are subject to the workflow’s configured timeout limits.
- Python version – Check the Amazon MWAA Serverless documentation for the currently supported Python runtime version.
- DAG format – MWAA Serverless uses YAML-based DAG definitions, not traditional Python DAG files. If you are migrating from MWAA Provisioned, you will need to convert your DAGs to the YAML format.
- Operators not supported – Some Airflow community operators and custom plugins are not available in the Serverless runtime. Refer to the documentation for the full compatibility list.
Clean up
To avoid ongoing charges, delete the resources you created in this walkthrough. The following commands remove the workflow, S3 objects, and IAM role:
Note: $WORKFLOW_ARN is defined in Step 7.
Note: $BUCKET is exported in Step 4. If appropriate, delete the bucket as well.
Conclusion
With native support for PythonOperator and BashOperator, you can now run the custom code execution patterns that many data engineering teams rely on daily directly in MWAA Serverless. Run data transformations, format conversions, validations, and shell scripts in the serverless runtime – without provisioning additional compute or managing containers.
If you are running Airflow workloads on MWAA Provisioned or self-managed infrastructure, your existing PythonOperator and BashOperator logic requires minimal changes. Convert your Python DAG files to the YAML format, package your code as a bundle, and you are ready to run on MWAA Serverless.
To get started, visit the Amazon MWAA Serverless documentation and try the walkthrough earlier in this post with your own data. For pricing details, visit the Amazon MWAA pricing page. We look forward to your feedback.