Managed Airflow (MWAA, Cloud Composer, Astronomer) - Commands & Configuration

Introduction

Running workflows can be complex and managing the infrastructure for them takes time. Managed Airflow services like MWAA, Cloud Composer, and Astronomer handle the setup and maintenance for you, so you can focus on creating and running your workflows easily.

When you want to schedule and monitor data pipelines without managing servers.

When your team needs a reliable way to automate tasks in the cloud.

When you want automatic scaling and updates for your workflow system.

When you prefer a ready-to-use Airflow environment with built-in security.

When you want to integrate with cloud services easily without manual setup.

Config File - example_dag.py

example_dag.py

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

default_args = {
    'start_date': datetime(2024, 1, 1),
}

dag = DAG(
    'example_managed_airflow_dag',
    default_args=default_args,
    schedule_interval='@daily',
    catchup=False
)

task1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag
)

task2 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    dag=dag
)

task1 >> task2

This is a simple Airflow DAG file that runs two tasks daily: printing the date and then sleeping for 5 seconds.

default_args sets the start date for the workflow.

DAG defines the workflow with a daily schedule.

BashOperator runs shell commands as tasks.

The last line sets the order: print_date runs before sleep.

Commands

This command creates a new MWAA environment named 'example-mwaa-env' with Airflow version 2.4.3. It specifies the S3 bucket where DAG files are stored, the execution role for permissions, and network settings for security.

Terminal

aws mwaa create-environment --name example-mwaa-env --airflow-version 2.4.3 --source-bucket-arn arn:aws:s3:::example-mwaa-bucket --dag-s3-path dags --execution-role-arn arn:aws:iam::123456789012:role/MWAA-Execution-Role --network-configuration SubnetIds=subnet-0123456789abcdef0,SecurityGroupIds=sg-0123456789abcdef0

Expected Output

{

    "Environment": {

        "Name": "example-mwaa-env",

        "Arn": "arn:aws:mwaa:us-east-1:123456789012:environment/example-mwaa-env",

        "AirflowVersion": "2.4.3",

        "Status": "CREATING"

    }

}

→

--name - Sets the environment name

→

--airflow-version - Specifies Airflow version

→

--source-bucket-arn - S3 bucket for DAGs

This command checks the status and details of the MWAA environment to know when it is ready to use.

Terminal

aws mwaa get-environment --name example-mwaa-env

Expected Output

{

    "Environment": {

        "Name": "example-mwaa-env",

        "Status": "AVAILABLE",

        "AirflowVersion": "2.4.3",

        "WebserverUrl": "https://example-mwaa-env.airflow.us-east-1.amazonaws.com"

    }

}

→

--name - Specifies which environment to check

Uploads the DAG file to the S3 bucket where MWAA reads DAGs from, so the workflow becomes available in the environment.

Terminal

aws s3 cp example_dag.py s3://example-mwaa-bucket/dags/example_dag.py

Expected Output

upload: ./example_dag.py to s3://example-mwaa-bucket/dags/example_dag.py

→

cp - Copy file to S3 bucket

Generates a login token URL to access the Airflow web interface for the managed environment.

Terminal

aws mwaa create-web-login-token --name example-mwaa-env

Expected Output

{

    "WebToken": "eyJraWQiOiJrMSIsImFsZyI6IlJTMjU2In0...",

    "WebServerHostname": "example-mwaa-env.airflow.us-east-1.amazonaws.com"

}

→

--name - Specifies the environment for login token

Key Concept

Managed Airflow services handle the infrastructure and let you focus on writing and running workflows easily in the cloud.

Common Mistakes

Uploading DAG files to the wrong S3 bucket or path.

The managed Airflow environment won't see the DAGs, so workflows won't run.

Always upload DAG files to the exact S3 bucket and folder configured for your environment.

Trying to access the Airflow UI before the environment status is AVAILABLE.

The environment is still setting up, so the UI is not ready and login will fail.

Check environment status with 'aws mwaa get-environment' and wait until it shows AVAILABLE.

Not assigning the correct IAM execution role with needed permissions.

The environment cannot access S3 or other AWS services, causing workflow failures.

Create and assign an IAM role with permissions for S3, CloudWatch, and other required services.

Summary

Create a managed Airflow environment with cloud CLI specifying version, S3 bucket, and network.

Upload your DAG files to the configured S3 bucket so the environment can run your workflows.

Check environment status before accessing the Airflow UI using a generated login token.

Practice

1. What is the main advantage of using a managed Airflow service like AWS MWAA or Google Cloud Composer?

easy

A. You don't need to manage the Airflow servers yourself.

B. You write DAGs in a new proprietary language.

C. You must manually install Airflow updates.

D. You cannot customize your workflows.

Solution

1. Step 1: Understand managed Airflow services

   Managed Airflow services handle the infrastructure and server management for you.

2. Step 2: Compare options

   The other options are incorrect because managed services still use Python DAGs, handle updates automatically, and allow workflow customization.

3. Final Answer:

   You don't need to manage the Airflow servers yourself. -> Option A

4. Quick Check:

   Managed Airflow = No server management [OK]

Hint: Managed means no server setup needed [OK]

Common Mistakes:

• Thinking you must manage Airflow servers manually
• Believing DAGs use a new language
• Assuming no workflow customization is possible

2. Which of the following is the correct way to upload your DAGs to AWS MWAA?

easy

A. Upload DAG files to an S3 bucket linked to MWAA.

B. SSH into the MWAA server and copy DAG files.

C. Use FTP to transfer DAG files to MWAA.

D. Email DAG files to AWS support.

Solution

1. Step 1: Identify MWAA DAG upload method

   AWS MWAA uses an S3 bucket to store DAG files that it reads automatically.

2. Step 2: Eliminate incorrect methods

   SSH and FTP are not supported because MWAA is fully managed and does not expose servers. Emailing files is not a valid method.

3. Final Answer:

   Upload DAG files to an S3 bucket linked to MWAA. -> Option A

4. Quick Check:

   MWAA DAGs stored in S3 bucket [OK]

Hint: MWAA DAGs live in S3 buckets [OK]

Common Mistakes:

• Trying to SSH into MWAA servers
• Using FTP which is unsupported
• Thinking AWS support manages DAG uploads

3. Given this snippet of a DAG uploaded to Google Cloud Composer, what will happen when the DAG runs?

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime
with DAG('example_dag', start_date=datetime(2024, 1, 1), schedule_interval='@daily') as dag:
    task1 = BashOperator(task_id='print_date', bash_command='date')
    task2 = BashOperator(task_id='sleep', bash_command='sleep 5')
    task1 >> task2

medium

A. The DAG runs once and fails due to syntax error.

B. The DAG runs daily but skips the sleep task.

C. The DAG runs daily but tasks run in parallel.

D. The DAG runs daily, printing the date then sleeping for 5 seconds.

Solution

1. Step 1: Analyze DAG schedule and tasks

   The DAG is scheduled daily starting Jan 1, 2024. It has two tasks: print_date and sleep.

2. Step 2: Understand task dependencies

   task1 >> task2 means task1 runs before task2. So print_date runs first, then sleep runs for 5 seconds.

3. Final Answer:

   The DAG runs daily, printing the date then sleeping for 5 seconds. -> Option D

4. Quick Check:

   schedule=@daily; task1 >> task2 [OK]

Hint: >> means run first task before second [OK]

Common Mistakes:

• Assuming tasks run in parallel
• Thinking the DAG has syntax errors
• Believing the sleep task is skipped

4. You deployed a DAG to Astronomer but it does not appear in the Airflow UI. What is the most likely cause?

medium

A. Astronomer does not support Python DAGs.

B. The DAG file has a syntax error preventing it from loading.

C. You need to restart the Astronomer platform manually.

D. The DAG file is too large to upload.

Solution

1. Step 1: Check DAG loading requirements

   Astronomer runs standard Airflow and requires valid Python DAG files to load and show in UI.

2. Step 2: Identify common loading issues

   If the DAG has syntax errors, Airflow will skip loading it, so it won't appear in the UI.

3. Final Answer:

   The DAG file has a syntax error preventing it from loading. -> Option B

4. Quick Check:

   Syntax errors block DAG loading [OK]

Hint: Syntax errors hide DAGs in UI [OK]

Common Mistakes:

• Thinking Astronomer doesn't support Python DAGs
• Assuming manual restart is needed
• Believing file size blocks upload

5. You want to ensure your DAG in AWS MWAA uses a custom Python package not included by default. What is the best way to add this package?

hard

A. Include the package code inside your DAG Python file.

B. Manually install the package on the MWAA server via SSH.

C. Create a requirements.txt file with the package and upload it to the MWAA environment.

D. Request AWS support to install the package for you.

Solution

1. Step 1: Understand MWAA custom package installation

   MWAA allows adding Python packages by uploading a requirements.txt file listing them.

2. Step 2: Eliminate incorrect options

   SSH access is not allowed, embedding package code in DAG is bad practice, and AWS support does not install packages on demand.

3. Final Answer:

   Create a requirements.txt file with the package and upload it to the MWAA environment. -> Option C

4. Quick Check:

   requirements.txt is standard for MWAA packages [OK]

Hint: Use requirements.txt to add packages in MWAA [OK]

Common Mistakes:

• Trying to SSH into MWAA servers
• Embedding package code inside DAG files
• Expecting AWS support to install packages