Driving an EKS Cluster from MWAA

Driving an EKS Cluster from MWAA An architecture diagram generated by Archify. MWAA managed runtime · Connected to customer private subnets · AWS-Managed MWAA Environment MWAA managed runtime Connected to customer private subnets MWAA worker: KPO · in_cluster=False · kubeconfig exec · AWS-Managed MWAA Environment · DAG MWAA worker: KPO in_cluster=False · kubeconfig exec DAG S3 bucket · DAGs + kube_config.yaml · Architecture component S3 bucket DAGs + kube_config.yaml Workload Pod · data-processing / workload-smoke · Your EKS Cluster (separate infra) Workload Pod data-processing / workload-smoke EKS access entry + RBAC · Execution role → namespace group · Architecture component EKS access entry + RBAC Execution role → namespace group EKS API · Authentication + namespace rights · Your EKS Cluster (separate infra) EKS API Authentication + namespace rights synced into runs HTTPS 443 + IAM group / RoleBinding create / watch AWS-Managed MWAA Environment Your EKS Cluster (separate infra)

Connectivity

  • • Worker subnet → EKS API DNS / HTTPS
  • • kubeconfig exec → MWAA execution role

Permission boundaries

  • • Access entry group → namespace RoleBinding
  • • Workload AWS identity configured separately

Operations

  • • S3 delivery + constraints + parsing checks
  • • DAG health, capacity and upgrades still matter