Short answer: When a scheduled flow run hasn’t started by its scheduled time. Details: - In Prefect 3.x Cloud, “Flow run late” indicates a run created by a deployment schedule has not entered Running by its scheduled start time. It can still be in Scheduled, Pending, or Queued—lateness is about time, not the specific pre-running state. - There’s no global, fixed grace period. If you want a specific threshold for alerts, set an SLA “Start within <duration>”. When that window is exceeded without the run starting, Cloud will notify you (this is what most users rely on for “late” alerts). - Manual/adhoc runs (no schedule) don’t have a scheduled start time, so they won’t be marked “late.” - “Flow run late” specifically applies at the flow-run level. Task runs generally aren’t marked “late” because they don’t have independent scheduled start times; use SLAs for task duration/behavior if needed. Docs: SLAs in Prefect 3 If you can share where you’re seeing “Flow run late” (UI banner vs. notification) and whether you have an SLA configured, I can confirm exactly what triggered it in your workspace.

Thanks for the timeline — that helps. What you’re seeing is expected behavior given how scheduling and pickup work: - 153002Z “Flow run scheduled” — this is when the scheduler created the run record (in advance). It’s not the start time. Your actual scheduled start was 230000Z. - 230030Z “Flow run late” — Cloud marks a run “late” shortly after the scheduled time if it hasn’t started yet. The ~30s delay is just the lateness checker running; there isn’t a global grace period. If you want a specific threshold for alerts, use an SLA “start within <duration>”. - 230346Z “Flow run pending” — this is when a worker finally claimed the run and submitted it to infrastructure. The ~3m46s delay means no worker had picked it up until then (usually due to worker availability, concurrency limits, or queue matching). Common reasons for the gap between 230000 and 230346: - No available worker at 23:00Z (worker offline or starting up) - Work pool/deployment/global concurrency limits blocking starts until a slot freed - Work queue filters/tags not matching until a change (less common) - Slow infrastructure cold start (K8s/ECS) — though note “Pending” is when the worker submits the job; “Running” follows after the container/pod actually starts How to confirm in your workspace: - Check worker status and logs around 2300–2304Z (Cloud UI → Infrastructure → Workers). You should see timestamps like “Picked up flow run …” and “Submitting flow run …”. - Check work pool concurrency and whether it was at capacity (Work Pools → your pool). - Check deployment concurrency, tags, and work queue filters. - Look at the run timeline for “claimed by worker”/“infrastructure started” events to see exactly when pickup occurred. If you share: - Worker type (Process, Docker, Kubernetes, ECS) - Whether you have any pool/deployment/global concurrency limits configured - A snippet of the worker logs around that window …I can pinpoint which of these caused the delay. Helpful refs: - SLAs in Prefect 3 - Worker healthchecks - Global concurrency limits - Work queues API

Thanks — with an ECS:push work pool there’s no always-on worker polling; Prefect Cloud “pushes” your run to AWS by calling ecs:RunTask at dispatch time. What your timeline means - 230000Z scheduled start: Run becomes eligible to be dispatched. - 230030Z Flow run late: The lateness checker saw the run hadn’t started yet and marked it late (~30s after the scheduled time). - 230346Z Flow run pending: This is when Prefect Cloud actually submitted the run to ECS and moved the run into Pending (i.e., “infrastructure requested, waiting to start”). So the “why” is: the push dispatcher did not submit the run to ECS until ~230346Z. Before that point there was nothing for ECS to start, so the run was “late” relative to 230000Z. Common reasons a push run isn’t dispatched right at the scheduled time - Temporary dispatch latency in the push pool (Cloud dispatchers run on a cadence and will retry on transient errors). - AWS throttling or transient API errors on ecs:RunTask that trigger short backoffs/retries. - A brief backlog of other runs being dispatched in the same region/pool. - Note: image pulls, container cold start, or cluster capacity affect the time from Pending → Running, not the gap before Pending. How to confirm in your account - In the run’s Timeline, look for the system event like “Submitted infrastructure” or similar; its timestamp should match ~230346Z. - In AWS CloudTrail, find the ecs:RunTask call for this run; its eventTime will show exactly when Prefect Cloud submitted it. If you see throttling errors preceding a success, that explains the delay. - Check ECS/CloudWatch events for capacity provider or API rate limit messages around 2300–2304Z. Ways to minimize this latency - If you need sub-minute pickup, consider a pull-based worker (e.g., ECS worker, Kubernetes worker, or a Docker/Process worker on a small always-on VM). Pull workers poll frequently and typically claim runs within seconds. - Keep everything in-region (ECR image, task execution role) to avoid cross-account/region overhead. This helps more with Pending → Running, but generally reduces friction. If you can share the run ID and region (and, if possible, any CloudTrail entries for ecs:RunTask around that time), I can help pinpoint whether this was dispatch cadence, AWS throttling, or something else.

Thanks for checking CloudTrail — that lines up: - Pending at 230346Z (Prefect UI) ≈ ecs:RunTask at 230349Z (CloudTrail) - No throttling/errors on AWS side → Prefect Cloud didn’t call RunTask until ~3m50s after the 230000Z schedule Why the gap with ECS:push - ECS:push pools are “push-dispatched” by Prefect Cloud. A background dispatcher periodically scans for eligible runs and submits them to ECS. It’s not a continuously polling worker. - Under normal load, that dispatcher cadence plus batching/queueing can introduce a delay of a few minutes even when there are no AWS errors. - If many runs hit the same scheduled minute (e.g., top-of-hour bursts), your run may be dispatched a little later in the batch. - Image pull/capacity/cold start affect Pending → Running, but your gap was before Pending, so this was purely dispatch latency. What you can do if you need tighter pickup - Use a pull-based worker (e.g., ECS worker/Kubernetes/Docker/Process). Pull workers poll every few seconds and typically claim runs within seconds. - If you stay on push, account for a few minutes of possible dispatch latency, and use an SLA “start within <duration>” for alerting. To double‑check it’s just dispatch timing, you can: - Compare a few other runs scheduled around 23:00Z; if they also show Pending a few minutes after schedule, it’s batching/cadence. - Look at the run’s timeline for “submitted infrastructure” — that timestamp should match your CloudTrail RunTask time. References: - SLAs: SLAs in Prefect 3 - Worker health: Worker healthchecks - Rate limits (background context): Prefect Cloud rate limits - Push vs pull background: Work pools and workers blog If you share the run ID and workspace, I can have our team review the dispatch logs to confirm this was standard push dispatch latency and not a transient retry on our side.

Yes — that pattern matches what we’d expect with an ECS:push pool. What’s happening - Near-term runs (created close to the start time or “Run now”) tend to be dispatched immediately via the “eager” path, so you see little/no delay. - Long-horizon scheduled runs are created well in advance and become eligible at the scheduled time. Push pools rely on a periodic dispatcher sweep to submit them to ECS. That sweep is on the order of minutes and can batch multiple runs, so you see a few minutes between scheduled time and the ecs:RunTask call even when there are no AWS errors. - Your CloudTrail RunTask at 230349Z aligns with this periodic sweep submitting the job several minutes after 230000Z. Ways to get tighter pickup - Prefer a pull-based worker (ECS/Kubernetes/Docker/Process). Pull workers poll every few seconds and typically claim runs within seconds of the schedule. - If you stay on push, budget a few minutes of dispatch latency and use an SLA “start within <duration>” for alerting. References - SLAs: SLAs in Prefect 3 - Worker health and behavior: Worker healthchecks - Background on push vs pull: Work pools and workers blog - Rate limits (context on background processing): Prefect Cloud rate limits If sub-minute start is important for these long-scheduled runs, I’d recommend switching this deployment to a pull-based ECS worker. If you want, share the deployment/work pool name and I can outline the exact steps to migrate.

Great question. Here’s a concise breakdown of pull vs. push in Prefect 3.x, and the operational tradeoffs. What “push” means (e.g., ECS:push) - How it dispatches: Prefect Cloud dispatches runs directly to your cloud provider (e.g., calls AWS ecs:RunTask) when a run becomes eligible. No always-on worker process. - Latency profile: A background dispatcher sweeps for eligible runs and submits them in batches — expect a potential delay of a few minutes for long-scheduled runs, but “Run now” and near-term runs are often picked up quickly. - Credentials and security: You grant Prefect Cloud credentials (e.g., an AWS block/keys/role) so Cloud can call the provider APIs on your behalf. - Ops overhead: Minimal. Nothing to operate 24/7. Good for low-frequency/batch workloads. - Cost: You only pay for your job’s infrastructure; no always-on worker to keep running. - Best for: Simplicity, low operational overhead, you’re okay with minute-level dispatch latency, and you’re comfortable giving Cloud the required cloud API access. What “pull” means (e.g., ECS worker, Kubernetes worker, Docker/Process worker) - How it dispatches: You run a worker process that polls your work pool, claims runs, then launches the job on your infra. - Latency profile: Typically sub-minute pickup; workers poll frequently and claim runs as soon as they’re eligible. - Credentials and security: Credentials stay in your environment (on the worker). Prefect Cloud does not need direct permission to your cloud account. - Ops overhead: Higher. You must run/monitor/update the worker (e.g., as a long‑running service on ECS/Kubernetes/VM), and handle availability/HA and scaling. - Cost: You keep a worker running (or autoscaling), in addition to paying for each job’s infrastructure. - Best for: Strict SLAs/near real-time starts, restricted networks/no outbound access from Cloud to your infra, or when you want maximum control over submission/runtime. Does pull require “more self-managed resources”? - Yes. With pull, you operate a long‑running worker (or a set of workers), ensure it has network access, IAM/role permissions, logging/monitoring, upgrades, and (optionally) autoscaling/HA. Push avoids all of that by letting Prefect Cloud submit jobs directly. Choosing between them - Choose push if you want the simplest setup and can tolerate a few minutes of dispatch latency for scheduled runs. - Choose pull if you need tight start times (sub‑minute), want credentials to remain inside your environment, or need custom control/observability on job submission. How to switch your deployment from ECS:push to pull (high level) - Create an ECS (pull) work pool (UI) and configure its base job template (cluster, task definition overrides, roles, region). - Run a worker that polls that pool (for ECS you’d typically run the worker as a small long‑running service in your cluster). - Point your deployment at the new pool. - Verify pickup latency on a test run; adjust polling/replicas as needed. Helpful references - Push vs pull background: Work pools and workers: deploy Python securely - Worker health/behavior: Worker healthchecks - AWS ECS guide (setup patterns and permissions): Prefect AWS ECS guide - SLAs (to alert on start delays): SLAs in Prefect 3 If you share your ECS setup (Fargate vs EC2, how you’d prefer to run a worker), I can outline a concrete plan (including IAM and runtime settings) to move this deployment to a pull-based ECS worker.

Short answer: Yes—“Hybrid” is Prefect’s term for pull-based execution. Clarifying the terms - Pull-based worker: A process you run in your own environment that polls a pull-type work pool and launches the flow run (e.g., to ECS, K8s, Docker, or locally). - Hybrid work pool (in Cloud UI/Docs language): A pull-type work pool that requires your worker. “Hybrid” just means the run executes in your infrastructure with your credentials; Prefect Cloud only orchestrates. Relationship - A hybrid work pool is a pull pool; it does nothing until a worker you run polls it. - Push pools are not hybrid; Prefect Cloud submits the job to your cloud (e.g., ecs:RunTask) without a worker. Security/ops differences - Hybrid/pull: Credentials stay in your environment; you operate the worker (more control, lower latency, more ops). - Push: Prefect Cloud needs permissions to call your cloud APIs; no worker to run (simpler, but dispatch can add a few minutes for long-scheduled runs). Getting started with pull - Create a pull-type work pool (UI is easiest), then run a worker that polls it:

prefect worker start -p "<your-pull-pool>"

References - Push vs pull background: Work pools and workers: deploy Python securely - Worker health/behavior: Worker healthchecks - ECS guide: Prefect AWS ECS guide

Great questions. Where to run it - Run

prefect worker start

on infrastructure you control that: - Can reach Prefect Cloud (outbound HTTPS) - Has credentials and network access to your execution backend - Typical placements: - ECS worker: run the worker as a small always-on service (ECS service or an EC2/VM) with IAM permission to call ECS (RunTask, DescribeTasks, etc.). It does not need to be in the ECS cluster, but must reach AWS APIs and your registry. - Kubernetes worker: run inside your cluster (as a Deployment). - Docker/Process worker: run on the host where you want containers/processes to start. Foreground vs background - By default,

prefect worker start

runs in the foreground and logs to stdout. It is intended to be kept running. - To run it “in the background,” use your process manager or container/orchestrator: - systemd example:

[Unit]
    Description=Prefect pull worker
    After=network-online.target

    [Service]
    Environment=PREFECT_API_KEY=YOUR_KEY
    ExecStart=/usr/bin/prefect worker start -p my-pull-pool
    Restart=always
    RestartSec=5

    [Install]
    WantedBy=multi-user.target

- Docker example (any image that includes Prefect 3):

docker run -d --name prefect-worker --restart unless-stopped \
      -e PREFECT_API_KEY=YOUR_KEY \
      <your-image-with-prefect-3> \
      prefect worker start -p my-pull-pool

Notes - Authenticate the worker (e.g.,

PREFECT_API_KEY

or

prefect cloud login

) before starting. - For ECS workers, ensure the worker’s IAM role covers ECS task submission and any ECR access required. - Pull workers typically give sub‑minute pickup; they must remain up/healthy. See health guidance here: Worker healthchecks - ECS setup patterns and required permissions: Prefect AWS ECS guide If you share which backend you’re targeting (ECS/K8s/Docker) and how you prefer to host the worker, I can provide a concrete unit/manifest with the right env vars and IAM scopes.

Yes. You can run

prefect worker start

on multiple servers (and/or run multiple replicas on one server) against the same pull-type work pool. Key points - Horizontal scaling: Multiple workers can poll the same work pool (and optionally the same work queues). Prefect Cloud arbitrates claims so each flow run is only picked up once. - Safe concurrency: Workers “claim” runs through the API; only one claim succeeds. Others back off. Use work pool/deployment/global concurrency limits to cap overall parallelism. - Resilience: If one worker host goes down, others keep polling and will continue to pick up runs. - Unique names: Give each worker a unique

--name

for clear observability in the UI. - Sharding (optional): Create multiple work queues under a pool to route by tags/filters. Point workers to specific queues with `-q`:

prefect worker start -p my-pull-pool -q high-priority -q nightly

Operational considerations - Each worker host must: - Reach Prefect Cloud (outbound HTTPS) - Have credentials/network to launch your jobs (ECS/K8s/Docker/etc.) - More workers = more potential parallelism; set limits to avoid cost spikes: - Work pool concurrency limit - Deployment concurrency limit - Global concurrency limits for shared resources - For ECS workers: run multiple small, always-on worker services (or increase desired count) to reduce pickup latency and provide redundancy. References - Worker health and failover: Worker healthchecks - Global concurrency limits: Global concurrency limits - ECS setup patterns and permissions: Prefect AWS ECS guide If you share your pool/queue setup and target infra (ECS/K8s/etc.), I can suggest a scaling pattern (e.g., number of workers, queue sharding, and concurrency settings).

Use the official Prefect image as your base, then add any extras your worker type needs. Recommended base - Docker Hub: prefecthq/prefect - Pin to a Prefect 3.x + Python tag to avoid surprises, for example: -

prefecthq/prefect:3.x.y-python3.11

- If you prefer a moving tag,

prefecthq/prefect:3-latest

(less reproducible) Add integrations for your worker type - ECS worker: needs AWS libs - Install either

prefect[aws]

or

prefect-aws

(plus boto3 if you use the latter) - Kubernetes worker: needs the k8s client - Install

prefect[kubernetes]

or

prefect-kubernetes

- Docker worker: needs Docker SDK - Install

prefect[docker]

Example Dockerfile for an ECS worker

FROM prefecthq/prefect:3.x.y-python3.11

# Add AWS integration
# Option A: extras
RUN pip install --no-cache-dir "prefect[aws]"
# Option B: split packages
# RUN pip install --no-cache-dir prefect-aws boto3

# (Optional) add any org-wide tools (e.g., opentelemetry, s3fs, etc.)

# Default command: start the worker and point it at your pull pool
CMD ["prefect", "worker", "start", "-p", "my-ecs-pull-pool"]

Running the worker container

docker run -d --name prefect-worker --restart unless-stopped \
  -e PREFECT_API_KEY=*** \
  # If running outside AWS, pass AWS creds/env or use an instance role where applicable
  # -e AWS_ACCESS_KEY_ID=... -e AWS_SECRET_ACCESS_KEY=... -e AWS_DEFAULT_REGION=...
  prefecthq/prefect:3.x.y-python3.11 \
  prefect worker start -p my-ecs-pull-pool

Notes - The worker image is separate from your flow-run image. For ECS/K8s, the worker only submits jobs; the actual flow runs in another container image (the one you configure in your job template/deployment). - Keep the worker image lean: Prefect + the integration(s) it needs. - Authenticate with Prefect Cloud using

PREFECT_API_KEY

. Keep the worker running (e.g., as a service/Deployment) for sub‑minute pickup. Helpful docs - ECS patterns and permissions: Prefect AWS ECS guide - Worker health/operations: Worker healthchecks - Background on work pools/workers: Work pools and workers blog If you tell me which worker type you’re running (ECS/K8s/Docker/Process) I can provide a ready-to-use Dockerfile tailored to that setup.

Yes, you can avoid ECR. You can run the worker from a public Prefect image on Docker Hub and do any needed installs at container start via the ECS Task Definition. How to run a pull worker on ECS without ECR - Image: use the public image

prefecthq/prefect:<your-3.x-tag>

(e.g.,

3.x.y-python3.11

or

3-latest

). - Command: install the ECS integration at startup, then start the worker. - Env: provide

PREFECT_API_KEY

(and

PREFECT_API_URL

if not using the default Cloud URL); AWS IAM via the task role. Example container definition (core pieces)

{
  "name": "prefect-worker",
  "image": "prefecthq/prefect:3.x.y-python3.11",
  "essential": true,
  "command": [
    "/bin/sh",
    "-lc",
    "pip install --no-cache-dir 'prefect-aws>=0.5.0' && prefect worker start -p my-ecs-pull-pool --name worker-$(hostname)"
  ],
  "environment": [
    { "name": "PREFECT_API_KEY", "value": "<YOUR_API_KEY>" }
    // If needed: { "name": "PREFECT_API_URL", "value": "<https://api.prefect.cloud/api/accounts/<acct>/workspaces/<ws>>" }
  ],
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/prefect-worker",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

IAM for the task role - Grant the worker permission to submit and query ECS tasks (RunTask, DescribeTasks, StopTask), plus any ECR pulls your flow-run jobs need (if those jobs use private registries). - The worker also needs outbound internet to reach Prefect Cloud and PyPI for the one-time

pip install

. Notes and trade-offs - Startup time: installing

prefect-aws

on container start adds ~seconds. If you want faster and fully pinned environments, a small custom image is ideal—but not required. - Rate limits: pulling from Docker Hub is anonymous; consider Docker Hub rate limits for very frequent restarts. Keeping the worker as a long-lived service minimizes pulls. - Separation of concerns: this image is just for the worker. Your flow runs (dispatched by the worker) can also use public images and fetch code via

flow.from_source(...)

so you can avoid ECR for those too. References - ECS guide and patterns: Prefect AWS ECS guide - Worker health/operations: Worker healthchecks - Background on push vs pull: Work pools and workers blog If you share your region and whether you’re on Fargate or EC2 launch type, I can sketch a complete Task Definition (CPU/memory, log config, minimal IAM policy) tailored to your setup.

Short answer: the worker is lightweight. Start small and scale by replicas. Recommended for an ECS pull worker (Fargate) - Baseline: 0.25 vCPU (256 CPU units) and 512 MB memory - If you install extras at startup (pip install) or want more headroom: 0.25 vCPU and 1 GB - Only increase further if you see OOM kills or heavy per‑second throughput needs; scaling out with more worker replicas is usually better than scaling up a single worker Why this works - The ECS pull worker does not run your flows; it just polls Prefect Cloud and submits ECS tasks, then periodically checks status. CPU/memory needs are modest and mostly network-bound. Throughput and HA tips - Run 2+ replicas for redundancy and faster pickup, spread across subnets/AZs - Control parallelism with work pool/deployment/global concurrency limits rather than big worker CPU - Watch for OOM/restarts in CloudWatch Logs; if seen, bump memory to 1 GB If you’re on Fargate, valid CPU/memory pairs include: - 0.25 vCPU: 0.5–2 GB (in 0.5/1 GB steps) - 0.5 vCPU: 1–4 GB - 1 vCPU: 2–8 GB - 2 vCPU: 4–16 GB - 4 vCPU: 8–30 GB Notes - The worker container’s resources are independent from your flow-run containers. Size your flow-run ECS tasks in the deployment/job template according to the workload. - If you install integrations on startup (e.g., pip install prefect-aws), 512 MB is typically fine; 1 GB gives more headroom during the install. References - Prefect AWS ECS guide - Worker healthchecks

There isn’t an official Docker image named

prefecthq/prefect-aws

. Use the official base image and add the AWS integration: - Official image: prefecthq/prefect - Pin a 3.x tag, e.g.

prefecthq/prefect:3.x.y-python3.11

(or

3-latest

if you’re okay with a moving tag) - AWS integration package: prefect-aws (you can also use the extras

prefect[aws]

) If you don’t want to build/push your own image (no ECR), you can install the AWS integration at container start in your ECS Task Definition: - Container image:

prefecthq/prefect:3.x.y-python3.11

- Command:

/bin/sh -lc "pip install --no-cache-dir 'prefect-aws>=0.5.0' && prefect worker start -p my-ecs-pull-pool --name worker-$(hostname)"

Notes - This pattern avoids maintaining a custom image. The trade-off is a few extra seconds for

pip install

on container start. - Keep the worker container lightweight; your flow-run containers can also use public images and fetch your code at runtime via

flow.from_source(...)

so you can avoid ECR for both worker and runs. - ECS setup guidance: Prefect AWS ECS guide

You’re right — thanks for the correction. I misspoke earlier. The image exists here: prefecthq/prefect-aws What it is - A convenience image that includes Prefect plus the AWS integration (and typical AWS deps like boto3), so you don’t need to

pip install prefect-aws

at startup. How to use it for a pull worker (no ECR required) - Reference the public image directly in your ECS Task Definition and start the worker:

# Container image
image: prefecthq/prefect-aws:<pin-a-3.x-tag>

# Command (examples)
command:
  - prefect
  - worker
  - start
  - -p
  - my-ecs-pull-pool
  - --name
  - worker-$(hostname)

# Environment (minimally)
PREFECT_API_KEY=***
# Optionally: PREFECT_API_URL if you use a non-default Cloud URL

Notes and recommendations - Pin a specific tag (and ideally a digest) from the Docker Hub tags page for reproducibility. Check the tags listed on the repo page to choose the Prefect/Python combo you want. - This image is great for the worker container because it avoids startup installs and keeps latency low. - Your flow-run containers can also use

prefecthq/prefect-aws:<tag>

if they need AWS libs (S3, SQS, etc.). If you want to avoid maintaining your own image, using this public image can work for both worker and runs. - CPU/Memory for the worker: start small (0.25 vCPU, 512 MB or 1 GB) and scale replicas rather than size. - IAM: the worker task role needs permission to submit ECS tasks (RunTask, DescribeTasks, StopTask) and whatever your flows need if you reuse this image for runs. - If you see Docker Hub pull limits with frequent restarts, keep the worker as a long-lived ECS service to minimize pulls. Helpful refs - Docker Hub repo: prefecthq/prefect-aws - ECS guide and patterns: Prefect AWS ECS guide - Worker health/operations: Worker healthchecks If you share which tag you’re considering and whether you’re on Fargate or EC2 launch type, I can sketch a full ECS task/container definition with the minimal IAM policy.

Yes — you can do both. Two separate actions to understand - Register block types (so they appear in the UI and API) - Create block instances (your saved configurations/credentials) CLI - Register block types from a module or file:

# Register all block types defined in a module (e.g., prefect-aws)
  prefect block register -m prefect_aws

  # Or register from a Python file that defines custom blocks
  prefect block register -f my_blocks.py

- List block types and configured blocks:

prefect block type ls
  prefect block ls

- Inspect/delete:

# Inspect a block instance by slug
  prefect block inspect aws-credentials/my-aws-creds
  prefect block delete aws-credentials/my-aws-creds

  # Inspect a block type
  prefect block type inspect aws-credentials

Python (create and save instances) - Once a block type is registered (many common ones are pre-registered in Cloud, but you can register explicitly), create instances in Python and save them:

from prefect_aws.credentials import AwsCredentials
from prefect_aws.s3 import S3Bucket

# Create AWS credentials block
aws_creds = AwsCredentials(
    aws_access_key_id="AKIA...",
    aws_secret_access_key="***",
    region_name="us-east-1",         # optional but recommended
    # role_arn="...",                 # alternatively, use role-based auth
    # session_token="...",            # if using STS creds
)
aws_creds.save("my-aws-creds", overwrite=True)

# Create an S3 bucket block that uses those creds
s3 = S3Bucket(
    bucket_name="my-bucket",
    credentials=aws_creds,           # or {"block_document_name": "my-aws-creds"}
)
s3.save("data-bucket", overwrite=True)

Notes - Prefer role-based auth for production (attach an IAM role to your worker or flow-run tasks) and create an

AwsCredentials

block that references the role instead of embedding long‑lived keys. - If a block type isn’t visible in your workspace, run

prefect block register -m <module>

once. - In code at runtime, you can load blocks with

AwsCredentials.load("my-aws-creds")

or

S3Bucket.load("data-bucket")

. Docs - Blocks overview: Blocks in Prefect 3 - CLI reference for blocks: prefect block CLI - AWS integration package: prefect-aws If you tell me which block you want to create (e.g., S3, Secrets Manager, ECS worker config), I can share an exact snippet.