<@ULVA73B9P> this document is for prefect v2:<http...
# ask-marvin
b
@Marvin this document is for prefect v2:https://github.com/PrefectHQ/prefect-demos/tree/main/flows/aws/datalake. Is there a similar diag for v3?
m
thought for 463.0 seconds
Short answer: I’m not aware of an official, one-to-one Prefect 3.x diagram that matches that v2 AWS datalake demo. The v3 docs don’t include a direct replacement diagram for that specific example. That said, here’s how the v2 architecture maps to v3 (workers + work pools), plus links to the most relevant v3 resources. If helpful, I can tailor a diagram to your exact AWS components. High-level reference sketch (Prefect 3.x)
Copy code
[Event or Schedule]
  ├─ (Option A) S3 event → Lambda → create Prefect flow run (API/Webhook)
  └─ (Option B) Prefect schedule / manual run

[Prefect Cloud / Server]
  └─ Work Pool ←→ Worker (e.g., ECS Worker) polls for work

[Execution]
  └─ ECS Worker launches ECS Task (Fargate/EC2) with your flow image
       ├─ Interacts with S3 (read/write via AwsCredentials)
       ├─ Triggers/monitors Glue jobs (optional)
       └─ Invokes Lambda or other AWS services as needed

[Observability]
  └─ Flow + task logs, retries, and states visible in Prefect UI
Key Prefect 3.x links - Workers & Work Pools overview: Blog: Work Pools and Workers - Migrating from agents (and using
flow.from_source(...).deploy(...)
): Upgrade: Agents → Workers - Integrations index: Integrations (v3) - AWS integrations (prefect-aws): Prefect AWS integration (v3) - ECS Worker guide: ECS Worker guide - Event-driven AWS pipelines with Prefect: Event-driven serverless on AWS - Managing data lakes with Prefect: Managing Data Lakes with Prefect If you share which AWS pieces you’re using (e.g., ECS vs. EKS, Glue involvement, event triggers from S3, etc.), I can draft a v3-specific diagram and example deployment config that mirrors your setup.
b
@Marvin Self hosted EKS which runs prefect cloud
m
thought for 72.1 seconds
Got it — thanks! Quick clarifier: do you mean - you’re using Prefect Cloud (SaaS control plane) and running your workers on your self‑hosted EKS cluster, or - you’re fully self‑hosting Prefect Server on EKS? If it’s Prefect Cloud + EKS workers, here’s the typical Prefect 3.x setup and how to get there quickly. High-level v3 sketch for EKS
Copy code
[Event or Schedule]
  ├─ (Option A) S3 event → Lambda → create flow run (Prefect Cloud API/Webhook)
  └─ (Option B) Prefect schedule / manual run

[Prefect Cloud]
  └─ Work Pool ←→ Kubernetes Worker (on your EKS) polls for work

[Execution on EKS]
  └─ Worker launches K8s Jobs/Pods for each flow run (image from ECR, etc.)
       ├─ Access AWS via IRSA (S3/Glue/Lambda/etc.)
       └─ Logs and states reported back to Cloud UI
Quickstart steps 1) Create a Kubernetes work pool (verified CLI)
Copy code
prefect work-pool create "eks-pool" --type kubernetes --paused
2) Deploy a Kubernetes worker on EKS with Helm - Add chart repo and install:
Copy code
helm repo add prefect <https://prefecthq.github.io/prefect-helm>
helm repo update

# Create a secret with your Prefect Cloud API key (example)
kubectl create secret generic prefect-api-key \
  --namespace prefect \
  --from-literal=key=YOUR_PREFECT_API_KEY

# Install the worker chart (values.yaml sets pool name, API URL, etc.)
helm install prefect-worker prefect/prefect-worker \
  --namespace prefect --create-namespace \
  -f values.yaml
- The worker container will run
prefect worker start --pool "eks-pool"
under the hood and poll for work. 3) Customize the base job template for K8s Jobs (service account, namespace, resources, IRSA) - When creating/updating the pool, add a job template:
Copy code
prefect work-pool create "eks-pool" --type kubernetes \
  --base-job-template ./k8s-job-template.json --overwrite
- Minimal example:
Copy code
{
  "job_configuration": {
    "namespace": "prefect",
    "serviceAccountName": "prefect-worker-sa",
    "imagePullSecrets": [
      {
        "name": "ecr-pull-secret"
      }
    ],
    "pod": {
      "annotations": {
        "<http://iam.amazonaws.com/role|iam.amazonaws.com/role>": "arn:aws:iam::<acct>:role/prefect-flows-irsa"
      }
    },
    "image": "<http://ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/your-flow-image:tag|ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/your-flow-image:tag>",
    "env": [
      {
        "name": "PREFECT_LOGGING_LEVEL",
        "value": "INFO"
      }
    ],
    "resources": {
      "requests": {
        "cpu": "500m",
        "memory": "1Gi"
      },
      "limits": {
        "cpu": "2",
        "memory": "4Gi"
      }
    }
  }
}
4) Deploy your flows to the pool - From your project root:
Copy code
prefect deploy
Follow the prompts to select your flow entrypoint, image, and the “kubernetes” work pool you created (eks-pool). Alternatively, package your code into an image (push to ECR) and reference it via the job template. Useful links - Workers & work pools overview: Work Pools and Workers (blog) - Upgrade to workers (and
flow.from_source(...).deploy(...)
): Upgrade: Agents → Workers - Integrations index: Integrations (v3) - Kubernetes integration index: prefect-kubernetes (v3) - Manage work pools: Manage work pools - Kubernetes deployment guide: Kubernetes guide - Helm deploy examples for workers: Deploy a worker with Helm - Helm for self-hosted server: Prefect Server via Helm (only if you’re self-hosting the control plane)
If you confirm Cloud vs. self-hosted Server, I can tailor a concrete diagram plus a values.yaml for the Helm worker (including IRSA, imagePullSecrets, resource defaults) to match your EKS setup.
b
@Marvin self hosted server
m
thought for 61.7 seconds
Great — here’s a Prefect 3.x architecture and setup tailored for a self‑hosted Prefect Server on your EKS cluster. High-level diagram (self‑hosted Server on EKS)
Copy code
[Triggers]
  ├─ S3/Lambda/Webhook → POST to Prefect Server API (/api)
  └─ Prefect schedules / manual runs

[Prefect Server on EKS]
  ├─ API + UI (Ingress)
  └─ Postgres (RDS recommended, or in-cluster)

[Execution on EKS]
  ├─ Kubernetes Work Pool (defined in Server DB)
  └─ Kubernetes Worker (Deployment) polls the Server API
        └─ For each flow run: Worker launches a K8s Job/Pod (your flow image)
             ├─ IRSA for AWS access (S3/Glue/Lambda/etc.)
             └─ Logs + states → Prefect UI
What to set up 1) Deploy Prefect Server to EKS (Helm) - Add the chart repo and install the server chart. Configure: - Postgres (external RDS strongly recommended) - Ingress with your hostname - Any UI exposure and TLS settings - Docs: Prefect Server via Helm Example (adjust to your values):
Copy code
helm repo add prefect <https://prefecthq.github.io/prefect-helm>
helm repo update

# Create a values file with your DB + ingress (server-values.yaml)
helm upgrade --install prefect-server prefect/prefect-server \
  --namespace prefect --create-namespace \
  -f server-values.yaml
2) Create a Kubernetes Work Pool (against your Server) - From your laptop/CI, point your CLI at your Server:
Copy code
export PREFECT_API_URL="<https://prefect.your-domain.com/api>"
prefect work-pool create "eks-pool" --type kubernetes --paused
3) Deploy a Kubernetes Worker on EKS (Helm) - The worker needs to know: - Your Server API URL (PREFECT_API_URL) - Which work pool to poll (e.g., eks-pool) - Docs: Deploy a worker with Helm - Kubernetes guide: Kubernetes guide Example install:
Copy code
# worker-values.yaml should set:
# - environment var PREFECT_API_URL=<https://prefect.your-domain.com/api>
# - command/args to run: prefect worker start --pool "eks-pool"
# - serviceAccount/IRSA if needed for AWS access

helm upgrade --install prefect-worker prefect/prefect-worker \
  --namespace prefect \
  -f worker-values.yaml
4) Configure the work pool’s base job template (for K8s Jobs) - Attach your service account (IRSA), namespace, image, resources, etc. - Docs: Manage work pools Example template (adjust fields to your cluster; use the docs as the source of truth):
Copy code
{
  "job_configuration": {
    "namespace": "prefect",
    "serviceAccountName": "prefect-flow-sa",
    "image": "<http://ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/your-flow-image:tag|ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/your-flow-image:tag>",
    "imagePullSecrets": [
      {
        "name": "ecr-pull-secret"
      }
    ],
    "env": [
      {
        "name": "PREFECT_LOGGING_LEVEL",
        "value": "INFO"
      }
    ],
    "resources": {
      "requests": {
        "cpu": "500m",
        "memory": "1Gi"
      },
      "limits": {
        "cpu": "2",
        "memory": "4Gi"
      }
    },
    "pod": {
      "annotations": {
        "<http://eks.amazonaws.com/role-arn|eks.amazonaws.com/role-arn>": "arn:aws:iam::<acct>:role/prefect-flows-irsa"
      }
    }
  }
}
Apply or update on the pool:
Copy code
prefect work-pool create "eks-pool" --type kubernetes \
  --base-job-template ./k8s-job-template.json --overwrite
5) Build and deploy your flows - Make sure your CLI points to your Server:
Copy code
export PREFECT_API_URL="<https://prefect.your-domain.com/api>"
- From your project root:
Copy code
prefect deploy
- Select your entrypoint, image (push to ECR), and target the “kubernetes” pool (eks-pool). AWS integrations you’ll likely use - Kubernetes integration index: prefect-kubernetes (v3) - AWS integrations index: prefect-aws (v3) - Use IRSA +
AwsCredentials
to access S3, Glue, Lambda, etc.
Notes specific to self-hosted Server - There are no API keys by default; your worker and CLI use
PREFECT_API_URL
to reach your Server. - Make sure your worker Pod can resolve and reach your Server API (in-cluster service DNS or external ingress). - Prefer RDS (managed Postgres) for resilience and maintenance. If you want, share: - Your planned hostname/ingress - Whether you’ll use in-cluster Postgres vs. RDS - Which AWS services you’ll hit (S3/Glue/Lambda) I can produce a concrete diagram and a pair of Helm values files (server + worker) tailored to your EKS setup.