How should you write requirements.txt for Amazon MWAA?

Start the file with a constraint statement for your exact Airflow and Python versions, pin each library with an exact version, and test the file locally with the MWAA local runner before uploading it. An unpinned package installs the latest release from PyPI, which can conflict with the rest of your list.

How MWAA installs your packages

Per the AWS documentation, you upload a requirements.txt file to the S3 bucket and tell MWAA which version of the file to use each time you change it. MWAA then runs a pip install on the scheduler and on each worker. Every component gets the same list.

The bucket needs Public Access Blocked and Versioning Enabled, which is also useful for audit: versioning means you can see which requirements file was active when.

The three rules

AWS gives these steps for a requirements file.

1. Add a constraints statement at the top. It points at the Airflow project's constraint file for your Airflow and Python version. If a package conflicts with the constraints, the pip install fails instead of installing something incompatible. For Airflow 2.7.2 and later, the docs say the file must include a constraint statement, and if you omit one MWAA specifies one for you.
2. Pin Airflow extras and libraries with the double equals operator. The docs say this prevents a future breaking update from PyPI from being applied automatically.
3. Do not list what the base install already has. The docs note libraries such as boto3 and psycopg2-binary are included in the base install and need no entry.

A skeleton looks like this, with your own versions in place of the placeholders.

--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-AIRFLOW_VERSION/constraints-PYTHON_VERSION.txt"
apache-airflow[amazon]==AIRFLOW_VERSION
some-library==1.2.3

Why unpinned is the risk

If a package is listed without a version, MWAA installs the latest release from PyPI. For a security reviewer that means the same file produces different environments on different days. A pinned file is reviewable and repeatable.

Pinning the direct dependencies is the minimum. The constraint file pins the Airflow side. Your own libraries and their sub-dependencies still deserve a look, so scan the resulting set.

Practical limits to know

• AWS recommends keeping the combined size of the libraries under 1 GB.
• If dependencies cannot install within ten minutes, the service times out and attempts to roll the environment back to a stable state. A large or slow requirements file is an availability risk as well as a startup cost.
• Install errors appear in the scheduler log stream named for the requirements install in CloudWatch Logs.

Test before you upload

AWS publishes a local runner that builds a container resembling the MWAA image. Add libraries one at a time to find a working combination, then freeze that into the file. Run your scanner against the same list in the same pull request.

Safeguard's SBOM and dependency scanning can read a requirements file and report known advisories for each pinned version, and the free scan at https://gold.safeguard.sh/scan lets you try it on a repository.

Quick check

Sources

• Installing Python dependencies on Amazon MWAA

Last reviewed: 19 October 2026.