AutoGineer
Generated banner for Authoring Mwaa Workflow
Generated logo for Authoring Mwaa Workflow

Authoring Mwaa Workflow

AWSOfficialPublished by AWS

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
Download ZIP

From the author

Authors and deploys MWAA workflow artifacts: Python Airflow DAGs for provisioned environments or YAML workflow files for Serverless. Covers operator selection, timeout design, retry strategy, scheduling, failure notifications, idempotency, and MWAA Serverless schema compliance. Deploys the artifact (S3 DAG upload or Serverless CreateWorkflow/UpdateWorkflow), creates an environment inline when approved, and redeploys fixes, then optionally hands off to testing-mwaa-workflow. Triggers on: create a DAG, write a pipeline, build a workflow, orchestrate tasks, Airflow DAG, data pipeline, schedule a job, deploy a DAG, deploy a workflow, YAML workflow. Not applicable to converting or migrating existing DAGs between provisioned and serverless (conversion is out of scope), running or smoke-testing a deployed workflow (handled by testing-mwaa-workflow) or diagnosing a failed run (handled by debugging-mwaa-workflow).
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured path for creating and deploying Amazon Managed Workflows for Apache Airflow (MWAA). It handles the distinct requirements for provisioned environments (Python DAGs) and MWAA Serverless (YAML workflows). The skill covers the entire lifecycle from operator selection, retry strategies, and scheduling to environment discovery and deployment. It includes built-in safety checks for state-mutating operations and integrates with testing workflows to ensure reliable pipeline delivery.

What it does

  • Routes requests between provisioned Python DAGs and Serverless YAML workflows.
  • Validates operator selection and configuration against MWAA-specific constraints.
  • Automates S3 uploads for DAGs and Create/UpdateWorkflow calls for Serverless.
  • Handles inline environment creation and redeployment of fixes.
  • Enforces security best practices for IAM, secrets management, and resource defaults.
  • Provides a clear hand-off mechanism to testing-mwaa-workflow for verification.

When to use it

  • When you need to create a new data pipeline or workflow for Amazon MWAA.
  • When you are unsure whether your project requires a provisioned environment or Serverless.
  • When you need to deploy a validated DAG or YAML workflow to an AWS environment.
  • When you need to update an existing workflow or redeploy a fix after testing.
  • When you require guidance on operator compatibility and retry strategies for MWAA.

Advantages

  • Reduces configuration errors by enforcing schema compliance and operator allowlists.
  • Ensures production safety through explicit confirmation of state-mutating operations.
  • Simplifies complex deployment steps into a guided, repeatable process.
  • Maintains consistency across different MWAA deployment models.
  • Integrates seamlessly with testing and debugging workflows for a complete lifecycle.

Usage examples

“Create a new Python DAG for my provisioned MWAA environment that runs a daily data sync.”
The agent will guide you through gathering context, selecting operators, and deploying the DAG to your S3 bucket.
“I need to deploy a new YAML workflow to MWAA Serverless.”
The agent will validate your YAML schema, check operator support, and execute the CreateWorkflow command.
“Deploy my DAG and run a test immediately.”
The agent will deploy the artifact and automatically invoke the testing-mwaa-workflow skill to verify the run.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/authoring-mwaa-workflow/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip authoring-mwaa-workflow.zip -d .agents/skills

Documentation by AWS

Authoring MWAA Workflows

AWS MCP server (optional but recommended): running the AWS CLI commands in this skill through the AWS MCP server gives sandboxed execution and audit logging. Every command here also works with the plain AWS CLI, so the skill does not require the MCP server or any MCP-only tools.

Author production-grade workflow artifacts for Amazon MWAA. Routes to one of two paths: Python DAG (provisioned) or YAML workflow (Serverless).

Execution note — poll in discrete steps: whenever you wait for an AWS operation to reach a terminal or ready state, issue one status check per call and decide in your own loop whether to check again. Never block a single command or script on the wait (no while+sleep until done), regardless of the operation or how long it takes.

Guardrail — where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference:

  • Loaded through the AWS MCP retrieve_skill tool: The skill is not installed on the local filesystem. You MUST fetch each reference via retrieve_skill with the file parameter (e.g. file="references/authoring-provisioned-dag.md") and read the returned content. Do NOT file_read these paths locally — they do not exist on disk.

  • Installed locally (e.g. .kiro/skills/authoring-mwaa-workflow/ or ~/.claude/skills/authoring-mwaa-workflow/): Read the files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through retrieve_skill.

Step 0: Route to Path

Evaluate in this order:

  1. Resolvable target provided? A target reference is a definitive routing signal regardless of other keywords:

    • A provisioned environment (ARN like arn:aws:airflow:<region>:<account>:environment/<name>, or a name resolvable via aws mwaa get-environment) → go to Path A.

    • A Serverless workflow ARN (arn:aws:airflow-serverless:<region>:<account>:workflow/<name>) → go to Path B.

  2. Both-path keywords present? If the request contains keywords from both paths and no resolvable target, disambiguate by intent:

    • PythonOperator is supported on Serverless, so an operator-level python cue (PythonOperator, python_callable, "Python function/task") alongside a Path B signal (yaml, serverless, workflow ARN) is NOT ambiguous → go to Path B.

    • Conversion context ("convert my Python DAG to serverless") → this skill does not apply; conversion is out of scope.

    • A genuine provisioned cue (Python DAG, provisioned) alongside a Serverless cue with no target → ask the clarifying question.

  3. Exactly one path keyword? Treat only deployment-target terms as Path A signals: provisioned, Python DAG, or "a .py for my environment" → go to Path A. yaml or serverless → go to Path B. Operator-level Python mentions are not Path A signals.

  4. No routing signal? "DAG" or "Workflow" alone is ambiguous — it does NOT indicate a path. Ask: is the target MWAA provisioned (Python DAG) or MWAA Serverless (YAML)?

Paths

Follow the reference for the path you routed to (you do not need the other path's reference):

After the routed path's Write step, continue with Deploy & Test below.

Deploy & Test (optional, after Write)

Authoring owns all deployment and redeployment. Detail in references/deploying-mwaa.md.

Steps

  1. Ask — present options based on whether the artifact has a schedule. Frame the question using path-appropriate language:

    • Provisioned: "deploy this DAG to an environment" (DAGs are uploaded to an environment's S3 bucket).

    • Serverless: "deploy this workflow" (workflows are standalone resources — never say "deploy to an environment").

    If the DAG/workflow has a schedule:

    • Deploy and test — deploy, unpause, trigger a run now

    • Deploy and unpause — deploy, unpause, let it run on schedule (no immediate trigger)

    • Deploy only — upload to S3, leave paused

    If the DAG/workflow has no schedule (manual-trigger only):

    • Deploy and test — deploy, trigger a run now

    • Deploy only — upload to S3, leave paused (no "unpause" option — nothing to schedule)

    The user may also decline all options.

  2. Deploy:

    • Provisioned: upload the DAG to the environment's SourceBucketArn/ DagS3Path. Run post-deploy verification (see deploying-mwaa.md) to confirm the scheduler parsed the new file without import errors or dag_id conflicts. If no environment exists and the user approves, create one inline (plan-validate-execute + explicit confirmation), then poll CREATING -> AVAILABLE (~20-40 min). The user may instead supply an existing environment.

    • Serverless: CreateWorkflow (new) or UpdateWorkflow (redeploy); the YAML is validated synchronously here. If the workflow uses PythonOperator/BashOperator, first build and upload the code package to S3 and pass it via --code (see references/serverless-code-packaging.md and references/deploying-mwaa.md). The user may instead supply an existing ARN.

    • Redeploy (fix loop): the same upload / UpdateWorkflow path, reused when testing-mwaa-workflow delegates an ARTIFACT or ENVIRONMENT fix.

  3. If "Deploy and unpause" selected — deploy per step 2, then unpause. Do not trigger a run or invoke testing-mwaa-workflow.

  4. If "Deploy and test" selected — deploy per step 2, unpause if applicable, then invoke testing-mwaa-workflow with the resolved target (env name + dag_id, or workflow ARN). That hand-off is testing's delegated invocation mode.

HARD GATE: If testing is requested — whether upfront ("deploy and test") or later in the conversation ("test it", "run it", "try it") — you MUST invoke testing-mwaa-workflow. Do NOT trigger, monitor, or verify DAG runs manually. "Deploy and unpause" is NOT a test request — it is a deploy-only action.

  • Production safety: create-environment, update-environment, create-workflow, and update-workflow mutate state — confirm each with its impact stated. Warn on prod-named targets.

Troubleshooting

ErrorCauseFix
dagrun_timeout kills DAG early< timeout set in service calledRaise dagrun_timeout or lower service timeout
YAML validation rejects workflowWrong type or paramUse timedelta format; check allowlist
Operator not found in ServerlessNot allowlistedUse a supported operator, PythonOperator/BashOperator, or Lambda
Serverless run: cannot extract code / corrupt envBad code packageFiles at zip root, no __pycache__, ≤250 MB; repackage
Serverless Python task ImportErrorMissing dep or wrong-platform wheelBundle as manylinux2014_x86_64 / Py3.12 wheel; don't bundle pre-installed packages
Template variable undefinedVersion mismatchCheck vars for exact Airflow version

References

Security Considerations

  • State-mutating operations (create/update-environment, create/update-workflow, S3 DAG upload) require explicit confirmation with impact stated; warn on prod-named targets (see the Deploy HARD-GATE).

  • Least-privilege IAM: the A5 check adds only the exact Action/Resource pairs the artifact needs — never *FullAccess or service:*.

  • No hardcoded secrets/endpoints: use Airflow Variables/Connections backed by Secrets Manager or SSM Parameter Store; never emit credentials in DAG code or CLI examples.

  • Serverless code packages ship only the user's own modules plus pinned, platform-matched wheels — no unreviewed third-party binaries.

  • Data protection: keep sensitive data out of SNS/CloudWatch notification payloads and logs; rely on their encryption.

  • Secure defaults for inline-created resources: encrypt and lock down any S3/MWAA/SNS/CloudWatch resource this skill creates — see deploying-mwaa.md "Secure defaults".

  • AWS security best practices: verify the security posture against the MWAA User Guide's Security best practices page (and the MWAA Serverless equivalent) at runtime — AWS updates them over time; see deploying-mwaa.md "Secure defaults".

Files

references/authoring-serverless-workflow.md

Authoring — Path B: YAML Workflow (MWAA Serverless)

Detailed steps for the Serverless / YAML path. The agent is routed here from the authoring-mwaa-workflow SKILL.md "Step 0: Route to Path"; it does not need the Provisioned (Path A) reference.

Path B: YAML Workflow (MWAA Serverless)

See yaml-schema.md for format and constraints.

B1. Gather Context

  1. Resource identifiers — look up via AWS tools. No placeholders.

  2. Schedule — NEVER use @daily/@hourly (or any @-preset) unless the user explicitly asks for that exact expression. If the user has no preference, derive a spread off-peak cron from the dag_id (minute 1-59, hour 1-6 UTC; see B4 rule 11) — never at the top of the hour, and do not reuse a single fixed time across workflows.

Airflow version is fixed by MWAA Serverless engine version (not user-chosen).

B2. Validate Operators

  1. Check operator is in the MWAA Serverless supported operators allowlist. See yaml-schema.md. PythonOperator and BashOperator ARE supported — prefer them for inline custom logic. Reach for another target only when the work does not fit the worker (1 vCPU / 3 GiB, 60-min task cap, no internet by default; confirm current worker limits from the AWS MWAA Serverless docs at runtime): use LambdaInvokeFunctionOperator when the user references an existing Lambda; offload heavy or long-running compute to Glue or EMR; give a task that needs internet a NetworkConfiguration VPC.

  2. Look up operator parameters for the correct provider version.

  3. Remove all unsupported task-level params: deferrable, trigger_rule, outlets, on_failure_callback, retry_exponential_backoff, max_retry_delay, pool, queue, etc.

  4. If any task uses PythonOperator/BashOperator, do B3 Custom Code & Dependencies before writing.

B3. Custom Code & Dependencies (only if using Python/Bash)

  1. Stdlib fast-path: if all imports in the callable/script are Python stdlib or builtins (e.g., time, json, os, math), skip the AWS doc fetch — no third-party dependencies exist. Go directly to step 1 (write the callable) then step 4 (packaging). Otherwise, fetch the authoritative runtime reference: https://docs.aws.amazon.com/mwaa/latest/mwaa-serverless-userguide/operators-python-bash-detail.html Extract: current pre-installed package list, Python version, and worker constraints. This is the source of truth — local references summarize but may lag.

  2. Write the callable/script the task runs. python_callable is referenced as module_name.function_name; the module is a .py file at the root of the code package.

  3. Determine third-party dependencies. Check each against the pre-installed package list from the AWS doc fetched in step 0. Do NOT bundle a pre-installed package — the pre-installed version wins and shadows a bundled copy; warn the user if they need a different version. Skip if stdlib fast-path applies.

  4. State the runtime constraints: dependencies must be manylinux2014_x86_64 wheels matching the Python version from the AWS doc (verify the platform tag and version against the step-0 doc if the runtime architecture changes); tasks have no internet by default (a package needing runtime network access requires a NetworkConfiguration VPC). Skip if stdlib fast-path applies.

  5. Packaging and deployment happen in the Deploy phase via --code; see serverless-code-packaging.md.

B4. Rules

  1. Timedelta format (REQUIRED): execution_timeout and retry_delay must use __type__: datetime.timedelta + seconds: N. Bare integers cause ValidationException.

  2. The first scheduled run must resolve to a future time (scheduled workflows). MWAA Serverless combines start_date with the next schedule-satisfying time-of-day and rejects the workflow only if that computed first-run time is already past. So start_date may be today as long as the schedule still fires later today; if today's only schedule-satisfying time has already passed, use a later date. Unscheduled workflows (schedule: null) have no first-run computation and may use any start_date, including a past one.

  3. XCom for small values only: Use S3 for larger payloads.

  4. No description in YAML — it is silently ignored. Pass descriptions via --description on create-workflow/update-workflow.

  5. Omit unsupported DAG params: max_active_runs, dagrun_timeout, catchup, tags, on_failure_callback, etc.

  6. Operator paths fully qualified: e.g., airflow.providers.amazon.aws.operators.athena.AthenaOperator.

  7. No aws_conn_id: MWAA Serverless controls credentials via execution role.

  8. Native operators for custom logic: use PythonOperator/BashOperator for inline custom logic and ship code via --code (see B3). Fall back to Lambda/Glue/EMR only per the B2 selection rule.

  9. No branching/conditional logic: BranchPythonOperator and the @task decorator are not supported; only PythonOperator and BashOperator are available for custom code. Keep control flow linear via dependencies.

  10. Idempotency: same as Python path — date-based suffixes.

  11. Schedule expression: NEVER emit @daily, @hourly, or any @-preset unless the user explicitly requests that exact expression. When the user gives no preferred time, DERIVE a spread off-peak cron from the dag_id so each workflow lands in its own slot — never reuse one fixed time across workflows. Do this at authoring time (you pick the value and write a literal cron into the YAML), so no runtime library is needed. Turn the dag_id into a stable integer n with this one fixed rule — always the same function, so the same dag_id derives the same n, and therefore the same slot, across every authoring session: a position-weighted sum n = sum(i * ord(c) for i, c in enumerate(dag_id, 1)) (order-sensitive, so word-order variants of a dag_id do not collide on one slot; needs no runtime library and always works). Do NOT substitute a different function (e.g. zlib.crc32, or Python's built-in hash(), which is also salted per process) — a different function yields a different n and a different cron for the same dag_id, breaking reproducibility. Then minute = 1 + (n % 59) (1-59, non-zero), hour = 1 + ((n // 59) % 6) (1-6 UTC), and schedule = "{minute} {hour} * * *". If you cannot compute n for any reason, still pick a varied off-peak time yourself (minute 1-59, hour 1-6 UTC) per workflow — NEVER give up, skip the schedule, fall back to a single fixed time, or use a @-preset.

B5. Write
workflow_name:
  dag_id: ...
  schedule: "<off-peak cron derived from dag_id; minute 1-59, hour 1-6 UTC; see B4 rule 11>"
  start_date: "<YYYY-MM-DD, chosen so the first scheduled run resolves to a future time; see B4 rule 2>"
  tasks:
    python_task:
      operator: airflow.providers.standard.operators.python.PythonOperator
      python_callable: my_module.clean_records
    task_name:
      operator: fully.qualified.path
      param: value
      retries: N
      retry_delay:
        __type__: datetime.timedelta
        seconds: N
      execution_timeout:
        __type__: datetime.timedelta
        seconds: N
      dependencies: [upstream_task]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · plugins/aws-data-analytics/skills/authoring-mwaa-workflow · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download authoring-mwaa-workflow.zip