Managed Airflow: MWAA and Cloud Composer
Architecture Diagram
Formal Definitions
Detailed Explanation
Managed Airflow Services
Managed Airflow services handle infrastructure management while you focus on DAG development. The three major providers are AWS MWAA, Google Cloud Composer, and Azure Managed Apache Airflow.
Key Insight: Managed services reduce operational overhead but you're still responsible for writing idempotent, well-tested DAGs.
Service Comparison
| Feature | MWAA | Cloud Composer | Azure Managed AA |
|---|---|---|---|
| Airflow Version | 2.x | 2.x | 2.x |
| DAG Storage | S3 | GCS | Blob Storage |
| Metadata DB | RDS PostgreSQL | Cloud SQL | Azure Database |
| Scaling | Manual (workers) | Auto-scaling | Manual |
| Monitoring | CloudWatch | Cloud Monitoring | Azure Monitor |
| Security | IAM, VPC | IAM, VPC | Azure AD, VNet |
| Version Upgrade | Manual | Auto or manual | Manual |
When to Use Managed vs Self-Managed
| Scenario | Recommendation | Reason |
|---|---|---|
| Small team, limited ops | Managed | Reduces operational burden |
| Large scale, custom needs | Self-managed | More control and flexibility |
| Multi-cloud strategy | Self-managed | Consistent across clouds |
| Regulatory compliance | Self-managed | Full control over infrastructure |
| Rapid prototyping | Managed | Faster time to production |
MWAA Setup
Cloud Composer Setup
MWAA DAG with S3 Storage
Service Comparison
| Feature | MWAA | Cloud Composer | Azure Managed AA |
|---|---|---|---|
| Airflow Version | 2.x | 2.x | 2.x |
| DAG Storage | S3 | GCS | Blob Storage |
| Metadata DB | RDS PostgreSQL | Cloud SQL | Azure Database |
| Scaling | Manual (workers) | Auto-scaling | Manual |
| Monitoring | CloudWatch | Cloud Monitoring | Azure Monitor |
| Security | IAM, VPC | IAM, VPC | Azure AD, VNet |
| Version Upgrade | Manual | Auto or manual | Manual |
| Min Workers | 2 | 2 | 2 |
| Max Workers | Configurable | Auto-scaled | Configurable |
| Price Model | Per environment + workers | Per environment + workers | Per environment + workers |
Scaling Thresholds
| Metric | Small | Medium | Large |
|---|---|---|---|
| DAG Count | <50 | 50-200 | 200+ |
| Task Count/Day | <1000 | 1000-10000 | 10000+ |
| Workers | 2-4 | 4-10 | 10-20 |
| Scheduler | 1 | 1-2 | 2+ |
| DB Instance | db.t3.medium | db.r5.large | db.r5.xlarge |
Best Practices
Security
- Use managed secrets: Leverage AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault instead of environment variables for sensitive data.
- Enable VPC peering: Run MWAA/Composer in private subnets with VPC peering for secure database and storage access.
Scaling and Performance
- Monitor worker utilization: Scale workers based on task queue depth and execution time, not just DAG count.
- Use Airflow variables for environment-specific configuration â avoid hardcoding in DAG files.
- Optimize parse time: Use dynamic DAG generation and minimize imports at module level.
Operations
- Implement CI/CD: Use S3 sync, GCS sync, or Git-based deployment for DAG updates.
- Enable logging: Configure all log types (scheduler, task, webserver) for debugging.
- Test upgrades: Use staging environments to test Airflow version upgrades before production.
Cost Optimization
| Strategy | Savings | Implementation |
|---|---|---|
| Auto-scaling workers | 30-50% | Scale based on queue depth |
| Right-size environment | 20-40% | Match class to workload |
| Off-peak scheduling | 10-20% | Schedule heavy jobs during low-cost hours |
| Spot instances | 60-70% | Use spot for non-critical workloads |
See Also
- Airflow Architecture â Core architecture and component overview
- Executors Comparison â Sequential, Local, Celery, and Kubernetes executors
- Databricks Provider â Databricks cluster and job management
- BigQuery Provider â Google BigQuery integration patterns