Planning material — fictional examples, no production behavior

Governed AI Sprint Delivery Orchestrator Cost Estimate

Status and scope

Planning estimate — 2026-08-02. Validate with the AWS Pricing Calculator and measured pilot usage before approving a production budget.

This document estimates the weekly AWS operating cost of the architecture in the implementation plan. It assumes a single pilot deployment in us-east-1, prices in US dollars, and the planned scale-to-zero behavior.

The estimate covers AWS infrastructure only. It excludes OpenAI API usage, GitHub plans and Actions overages, engineering labor, taxes, AWS Support, and free-tier credits. Those costs should be budgeted separately; model usage can exceed the AWS infrastructure cost.

Weekly planning range

Usage scenario Sprints per week Issues per week Estimated AWS cost per week
Deployed but idle 0 0 $1–$3
Light 2 sprints × 10 issues 20 $2–$6
Typical 3 sprints × 15 issues 45 $4–$11
Heavy 5 sprints × 20 issues 100 $8–$22
Inefficient or unusually chatty 5 sprints × 20 issues 100 $15–$35

Use $8–$15 per week as an initial operating expectation for regular pilot use and $25 per week as a conservative AWS planning allowance. Set a monthly AWS Budget alert at $75 initially and investigate any projection above $100 per month.

These ranges are not a quote. The largest uncertainties are how long Aurora remains awake, how much application logging is retained, and how often GitHub events wake workers while builds and reviews are in progress.

Workload and configuration assumptions

The ranges assume:

The implementation should record actual Fargate task-seconds, Aurora ACU-hours, log ingestion, model usage, and per-run counts so this estimate can be replaced with measured cost per issue and cost per sprint.

Typical-week cost composition

For approximately three 15-issue sprints in one week:

Component Estimated weekly cost Primary cost basis
Aurora compute $1–$5 Active ACU-hours and wake duration
Aurora storage, I/O, and backups $0.20–$1 Stored GB, request I/O, backup growth
ECS Fargate and task public IPv4 $0.40–$1.50 Worker vCPU, memory, duration, and IP-hours
CloudWatch $0.75–$2.50 Log ingestion/retention, alarms, custom metrics
Secrets Manager about $0.30 Stored secrets and low API-call volume
API Gateway, Lambda, SQS, and DynamoDB under $0.25 Low-volume requests and duration
ECR, S3 state, and miscellaneous storage $0.10–$0.50 Stored images and state versions
Likely total $4–$11 Rounded planning range

The component ranges are correlated and should not be interpreted as independent maxima. The scenario total is the controlling estimate.

Pricing basis

The estimate uses public on-demand pricing available on 2026-08-02:

AWS can change prices independently of this plan. Recalculate before the first apply and at least quarterly during the pilot.

Cost behavior by state

Idle but available

The planned normal idle state leaves API Gateway, Lambda, SQS, DynamoDB, Secrets Manager, ECR, S3 state, CloudWatch, and Aurora storage provisioned. Fargate remains at desired count zero and Aurora automatically pauses. This preserves webhook and operator ingress while avoiding continuous worker and database compute charges.

The remaining $1–$3 weekly estimate primarily covers secrets, alarms, stored logs and images, database storage/backups, and small request volumes.

Active sprint processing

Ingress wakes up to two Fargate tasks. The workers resume Aurora, claim durable work, perform orchestration, and stop after the queue and leases are clear. Because implementation builds run in GitHub Actions, elapsed sprint duration must not be treated as Fargate runtime. Waiting should be event-driven.

At the assumed worker size, Fargate plus its public IPv4 address costs roughly $0.054 per running task-hour. Ten to 35 task-hours therefore cost about $0.55–$1.90 before logs and other AWS services.

Failure to pause

Aurora is the most important cost-control boundary. At $0.12 per ACU-hour, an instance that stays active for all 168 hours in a week costs approximately:

Open connection pools, polling, frequent reconciliation, or a worker that does not terminate can prevent the intended pause. The inefficient scenario range includes this failure mode.

Sensitivity and exclusions

Model and GitHub execution

OpenAI planning, feasibility, review, and repair calls are excluded because their cost depends on the selected model, token volume, cached-input behavior, and number of repair cycles. GitHub-hosted Actions usage is also excluded because included minutes and overage rates depend on repository ownership and plan.

Track both costs per issue. A sprint estimate is incomplete if it reports only AWS spend. Allocate model usage according to the OpenAI usage attribution and project strategy so target-application totals remain visible in the OpenAI console while workflow-stage detail remains available in orchestrator telemetry.

Logging

Verbose payload logging can turn CloudWatch into the second-largest AWS cost. Do not log raw model reasoning, credentials, webhook secrets, or complete payloads. Use structured summaries, bounded retention, sampling for repetitive events, and explicit log-level controls.

Deployment and recovery testing

Terraform applies, database migrations, runtime smoke tests, crash-recovery tests, and intentional multi-worker exercises produce short bursts above the normal run rate. Reserve an additional $2–$10 in weeks containing repeated infrastructure or recovery testing.

Required cost controls

Before enabling the pilot:

  1. Configure an AWS Budget with alerts before or in the same protected apply that creates application resources.
  2. Enforce Fargate desired count 0–2; alarm when tasks run beyond the expected sprint window.
  3. Pin an Aurora PostgreSQL version that supports 0 ACUs, configure the five-minute auto-pause interval, and alarm on unexpected ACU-hours.
  4. Ensure worker shutdown closes PostgreSQL pools and releases or checkpoints leases.
  5. Set CloudWatch retention explicitly and prohibit unbounded debug logging.
  6. Apply ECR lifecycle retention and avoid retaining redundant images.
  7. Tag all resources with environment, application, and cost-allocation tags.
  8. Record per-run AWS usage proxies and model token usage in the cost and provenance records already required by the implementation plan.
  9. Review Cost Explorer weekly during the pilot and revise these ranges after the first two, five, and ten completed sprints.
  10. Keep the operator drain control and test that it safely returns Fargate to zero without abandoning active leases.

Validation checkpoints

Replace planning assumptions with evidence at these points: