Infrastructure costs and sizing
AlphaAgent Studio runs entirely in your AWS account, so you pay AWS directly for the infrastructure it provisions. This page explains what that infrastructure is, how it is sized, and gives a rough monthly cost estimate so you can budget before you deploy.
There are two independent things you pay for:
- AWS infrastructure — the always-on compute, networking, storage, and data stores Studio runs in your account. This page estimates that layer.
- Usage-based AI + platform costs — Amazon Bedrock model inference (billed by AWS per token, scales with how much your team uses Studio) and your Prometheus Research Labs license. These are not included in the figures below, because they depend entirely on your workload.
The numbers here are the fixed AWS baseline — what the stack costs to keep running before anyone sends a single prompt.
All figures use public AWS list prices for us-east-1 as a sample region and a 730-hour month, and exclude any savings plans, credits, or committed-use discounts. Your real bill depends on your region, actual usage (DynamoDB, S3, data transfer, EFS, Bedrock), and any AWS discounts. Treat these as a planning guesstimate, not a quote.
How Studio is sized
Studio is deliberately over-provisioned for reliability, not cost-minimised. A single deployment is intended for a team of roughly 8–10 users running several concurrent workflows and deep-traversal analyses at once — so the services are sized generously to keep everything stable under load rather than tuned to the cheapest configuration that "just works".
The backend is a set of containerised services running on AWS Fargate (serverless containers — no EC2 instances to manage). Each service runs as a single task — capacity lives in one larger, vertically-sized task rather than multiple copies. This is deliberate: several services hold live session state in process memory (agent-runtime's active sessions, code-interpreter and knowledge-base-mcp per-session handles), and Studio's internal east-west traffic is round-robined by ECS Service Connect with no session affinity, so a second replica would send roughly half of a session's follow-up calls to the task that does not hold it. The graph database (Neo4j, when self-hosted) likewise runs as a single task.
Studio offers five sizing tiers — xs, small, standard (the default), large, and xlarge — that you choose at install and can change later (see Sizing tiers below). The table below is the default standard tier:
| Service | vCPU | Memory | Tasks |
|---|---|---|---|
| agent-runtime | 16 | 64 GB | 1 |
| knowledge-base | 16 | 64 GB | 1 |
| knowledge-base-mcp | 8 | 32 GB | 1 |
| neo4j (self-hosted) | 8 | 32 GB | 1 |
| agent-management | 4 | 16 GB | 1 |
| chat | 4 | 16 GB | 1 |
| data-connector | 4 | 16 GB | 1 |
| workflow | 4 | 16 GB | 1 |
| code-interpreter | 4 | 16 GB | 1 |
| web-browser-search | 4 | 16 GB | 1 |
| notification-service | 4 | 16 GB | 1 |
Total running fleet: about 76 vCPU and 304 GB of memory across 11 tasks.
A new AWS account's default Fargate concurrent vCPU quota is 140, comfortably above Studio's ~76 vCPU fleet. Updates are applied without temporarily doubling the fleet (old tasks stop before new ones start, behind a maintenance screen), so a default account never needs a quota increase. See Prerequisites → AWS service quotas.
Self-hosted Neo4j is included above (8 vCPU / 32 GB).
Sizing tiers
Studio offers a ladder of five sizing tiers. You pick one interactively during studioctl install (or non-interactively with --sizing / a --config entry / the STUDIO_SIZING_PROFILE environment variable), and you can change it later on a live deployment with studioctl reconfigure (no version bump) or as part of a studioctl update.
| Tier | Total vCPU | Total memory | Roughly |
|---|---|---|---|
| xs | ~19 vCPU | ~76 GB | evaluation / 1–2 users |
| small | ~38 vCPU | ~152 GB | small teams (~2–5 users) |
| standard (default) | ~76 vCPU | ~304 GB | ~8–10 concurrent power users |
| large | ~76 vCPU | ~456 GB | heavier KBs / long runs (~10–15 mixed users) |
| xlarge | ~76 vCPU | ~570 GB | maximum single-task headroom |
large and xlarge add memory, not CPUAt the standard tier the two heavy services (agent-runtime and knowledge-base) are already pinned at 16 vCPU per task — the Fargate per-task maximum. The large and xlarge tiers therefore add memory only; they do not raise vCPU above standard. Going beyond xlarge's raw throughput would require horizontal scaling, which Studio does not currently support (each service runs as a single task — see above).
Below standard, small allocates about half the vCPU and memory of standard (Neo4j's JVM heap and page-cache scale down to match so it still starts cleanly), and xs is a minimal evaluation footprint. Smaller tiers cut the Fargate compute line (the largest fixed cost) but trade headroom for cost: heavy deep-traversal or knowledge-graph builds have less memory to work with, so very large jobs may run slower or, at the extreme, hit memory limits. You can move up or down the ladder at any time with studioctl reconfigure or an update.
A deployment installed before the tier ladder existed may have recorded the older
reducedprofile name. It is a deprecated alias ofsmall(identical sizing) and is migrated automatically on the next reconfigure or update.
ElastiCache (Redis) node type
The Redis cache runs as a 2-node Multi-AZ ElastiCache replication group. Its node type is selectable at install and changeable later. The default is cache.t4g.medium (burstable, ~3.1 GB); larger options include cache.t4g.large, cache.m7g.large, cache.r7g.large, and cache.r7g.xlarge for larger working sets or heavier concurrent load (or any other valid ElastiCache node type). Set it with --redis-node-type at install, or change it later with studioctl reconfigure. A node-type change is applied online but triggers a brief failover/reconnect, so it is best run inside a maintenance window.
What you pay for
| Layer | Component | Billing model |
|---|---|---|
| Compute | Fargate (the service fleet above) | Per vCPU-hour + per GB-hour, always on |
| Cache | ElastiCache for Redis | Per node-hour, always on |
| Networking | NAT Gateway, Application Load Balancer, VPC interface endpoints | Per hour + per GB/LCU processed |
| Storage | EFS (self-hosted Neo4j), S3 buckets | Per GB stored (usage-based) |
| Data stores | DynamoDB (on-demand) | Per request + per GB stored (usage-based) |
| Secrets / logs | Secrets Manager, CloudWatch Logs | Per secret / per GB ingested |
| AI (separate) | Amazon Bedrock model inference | Per token — not included here |
Rough monthly estimate (us-east-1)
Using us-east-1 Fargate Linux/ARM64 list prices — $0.03238 per vCPU-hour and $0.00356 per GB-hour — over a 730-hour month:
| Item | Basis | Est. monthly |
|---|---|---|
| Fargate — vCPU | 76 vCPU × $0.03238 × 730h | ~$1,796 |
| Fargate — memory | 304 GB × $0.00356 × 730h | ~$790 |
| ElastiCache Redis | 2 × cache.t4g.medium (default node type) | ~$100 |
| NAT Gateway | 1 gateway (hourly) | ~$33 + data |
| Application Load Balancer | 1 ALB (hourly) | ~$16 + LCU |
| VPC interface endpoints | ~9 endpoints × AZs | ~$100–130 |
| Secrets Manager | ~16 secrets | ~$6 |
| EFS / DynamoDB / S3 / data transfer | usage-based | varies |
| Fixed AWS baseline (excl. Bedrock) | ~$2,850–3,000 / month |
Low / medium / high
To bracket the uncertainty in the usage-based and networking line items:
| Scenario | What it assumes | Est. fixed AWS baseline |
|---|---|---|
| Low | Default self-hosted setup, light data/networking | ~$2,500–2,700 / month |
| Medium | Default self-hosted setup, moderate usage | ~$2,850–3,000 / month |
| High | Self-hosted Neo4j, heavy data transfer, large EFS/S3/DynamoDB footprint | ~$3,300–3,800 / month |
All scenarios exclude Amazon Bedrock token costs and your Prometheus Research Labs license, which are usage-driven and tracked separately.
Ways to reduce cost
- Use a smaller sizing tier —
small(about half the vCPU and memory ofstandard) orxs, chosen at install or switched later withstudioctl reconfigureor an update. See Sizing tiers. - AWS Savings Plans / Compute Savings Plans apply to Fargate and can cut the compute line materially for a 1- or 3-year commitment.
- Choose a cheaper region if your data-residency requirements allow —
us-east-1is used here only as a sample. Studio can only deploy into the supported US/EU regions.
See also
- Prerequisites — quotas and account readiness.
- Overview and architecture — what runs in your account.
- What runs in your account — the component inventory.