What runs in your account (Studio)
A Studio deployment is five CloudFormation stacks in one of your AWS accounts, plus a handful of resources the engine and Studio itself create at runtime. This page walks the components from the front door inward and ends with a resource inventory derived from the templates.
Who this is for
Security engineers reviewing the footprint, and cloud engineers who need to know what a deployment costs and why. The end-user view of the same features is in the Studio guide.
Before you start
Stack names are alphaagent-<deployment id>-<suffix>. Resource names use the project prefix alphaagent and, for buckets, your account id and region. Everything below is created with CAPABILITY_NAMED_IAM, so the role names are fixed and predictable.
The network
The core stack creates a dedicated VPC in the range you chose for the deployment, with two private subnets across two availability zones. Tasks, the load balancer and sandboxes run in the private subnets. Outbound internet traffic, which carries the licence heartbeat to the Console, agent web search and calls to your data sources outside AWS, leaves one of two ways, chosen when the deployment was created:
- Through AlphaAgent's NAT gateway. The core stack adds two public /28 subnets holding one NAT gateway with an Elastic IP, and an internet gateway. Nothing else sits in the public subnets.
- Through your Transit Gateway and your firewall. The VPC has no internet gateway, NAT gateway, Elastic IP or public subnet. The private network stack routes 0.0.0.0/0 to your Transit Gateway and adds six interface endpoints (Lambda, EventBridge, SNS, CloudWatch, Bedrock and Session Manager messages) so AWS calls stay on AWS.
The private network stack (-private-network) connects the VPC to your network. The job first requests a Transit Gateway attachment of the two private subnets through the EC2 API and waits for your network team to accept it; the stack then adds one route per user access range and per internal service range to your Transit Gateway, the load balancer's HTTPS and HTTP ingress from each user access range, and sandbox egress to each approved internal range on each approved port. With outbound traffic through your Transit Gateway it also routes every other address in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 to a network interface that is never attached, so a private range you did not list is dropped inside the VPC instead of reaching your network. Routes name the Transit Gateway, not the attachment, so a replacement attachment brings them back with no stack change. Your side of the attachment is on Private network access.
Ten VPC endpoints keep AWS traffic inside the VPC: gateway endpoints for S3 and DynamoDB, and interface endpoints for Secrets Manager, STS, ECR (API and Docker registry), CloudWatch Logs, SQS, Systems Manager and Bedrock Runtime. Model calls never leave the VPC for the public internet.
Five security groups separate the load balancer, the tasks, the sandbox Lambda functions, Redis and the EFS mount targets. The load balancer's admits HTTPS and HTTP from the VPC range, and the private network stack adds your user access ranges. The sandbox security group allows outbound TCP 443, plus the approved ports to the approved internal ranges.
How requests reach Studio
- Your network. Users and API callers in a user access range reach the app domain through your private DNS zone (associated with the deployment's VPC) and your Transit Gateway. Nothing about the deployment is reachable from the internet.
- Existing public deployments. A deployment created before private network access keeps its CloudFront front door: a distribution whose alias is your app domain (TLS 1.2 minimum, HTTP redirected to HTTPS, certificate requested in
us-east-1), one smallnodejs24.xLambda@Edge origin-response function inus-east-1, and an origin lock: a 24-byte secret,alphaagent-<deployment id>-edge-origin, that CloudFront adds as theX-AlphaAgent-Edgeheader and every listener rule requires, so a request that bypasses CloudFront gets a fixed 403. Its load balancer is internet-facing. - The load balancer is internal, in the private subnets. It listens on 443 with the certificate you supply in the deployment region (security policy
ELBSecurityPolicy-TLS13-1-2-2021-06) and redirects 80 to 443. Every rule except one adds anauthenticate-cognitoaction in front of the target: an unauthenticated browser is sent to sign in. The exception is/api/v1, the programmatic API, which the workflow service protects with API keys instead; see Programmatic access. - Optional WAF. When the deployment sets
ApiWafIpSetCidrs, the stack creates a regional Web ACL with one rule that blocks/api/v1from any source outside the allow-list. Every other path passes. Without CIDRs, no WAF resources are created. - Cognito. One user pool per deployment, with a SAML identity provider named
AlphaAgentSSOthat federates to your Entra ID tenant. Password sign-in is not offered to users; see Identity and access.
Services
All services are ARM64 Fargate tasks in one ECS cluster, reached through the load balancer and, between themselves, through Service Connect.
| Service | Role in the deployment |
|---|---|
agent-management | Agents, execution environments, active configurations, the Libraries browse and pull path, the Agent Store client, provisioning of sandbox Lambda functions |
agent-runtime | Runs conversations and workflow runs, the licence activation and heartbeat, the usage outbox drainer, PII redaction |
chat | Conversations, messages and summaries |
data-connector | Connector definitions, credential storage, connection tests and connector guides |
workflow | Workflow definitions, versions, runs and schedules; the programmatic API at /api/v1 |
knowledge-base | Knowledge graph document processing and version builds |
knowledge-base-mcp | Knowledge graph retrieval for agents |
code-interpreter | The coder that writes and runs code, and the dispatch of each execution to a sandbox |
web-browser-search | Web search (a bundled SearXNG) and page browsing (headless Chromium) |
notification-service | Inbox cards and banners |
neo4j | The self-hosted graph store, single node, data on EFS |
A twelfth task definition, kg-transfer, has no service: the Organisations engine starts it on demand to export or import a knowledge graph version during a Library transfer.
Sizing is one SizingProfile per deployment; the console offers xs, small, standard, large and xlarge (the template also accepts a reduced value the console does not offer). Services are grouped Heavy (agent-runtime, knowledge-base), Mid (knowledge-base-mcp, neo4j) and Light (everything else), and each group gets a vCPU and memory pair from the profile. At standard the Heavy pair is 16 vCPU and 64 GB, the Fargate per-task CPU ceiling; large and xlarge add memory only.
Sandboxes
Agent code runs in AWS Lambda, not in the ECS tasks. agent-management creates one Lambda function per execution environment, named alphaagent-env-<environment id>, from the environment's container image in the alphaagent-envs ECR repository, inside the VPC on the sandbox security group. Each execution is one invocation. Per-invocation credentials are narrowed to the invoking user's workspace prefix and the invoking agent's connector secret; the mechanics are on Sandbox isolation.
Data stores
- DynamoDB: 38 tables, all on-demand capacity, grouped by service: agents, environments and active configurations; chat conversations, messages and summaries; workflow definitions, versions, executions and schedules; execution runs, run events and run boards; connectors and agent-connector links; knowledge graphs, documents, jobs and build state; notifications and activity; API keys; share requests; the metering outbox. Stateful tables carry
DeletionPolicy: Retain. - S3: seven buckets from the core stack, each with SSE-S3 (AES-256) default encryption, versioning and all public access blocked:
workspaces(every user's files, run inputs and outputs),kb-artifacts(uploaded documents),kb-processingandkb-dgl-training(knowledge graph build state),chat-overflow(large payloads and the staged sandbox handler),code-scripts, andfrontend(the Studio web app). The engine also createsalphaagent-deploy-<account>-<region>on first use to hold CloudFormation templates. - Neo4j on EFS: one encrypted EFS file system with elastic throughput and AWS Backup enabled, two mount targets, and two access points (
/dataand/logs) for the Neo4j task. - Redis: one ElastiCache replication group (default node type
cache.t4g.medium) with at-rest and in-transit encryption, used for sessions and runtime cache. - Secrets Manager: 18 secret shells from the core stack (one
-configsecret per service plus common configuration, the licence bootstrap and persisted licence secret, Neo4j credentials, and the PII hash key), populated at install. Studio adds the data-connector credential secret, one connector-credential secret per agent, and the prompt key after activation. - SQS: three queue pairs (main plus dead-letter) for knowledge graph processing, notification events and workflow schedules. EventBridge rules are created per workflow schedule at runtime.
- CloudWatch: one log group per service (
/alphaagent/services/<service>), retentionLogRetentionInDays(default 30), plus alarms on the task-definition stack.
Steps: read the inventory from your own account
- Open CloudFormation in the deployment region, select the
-corestack and open Resources. Compare the list with the table below. - Repeat for
-stateless,-private-network,-computeand-taskdef. - In VPC, open Transit gateway attachments: one attachment tagged
alphaagent:deploymentwith your deployment's id, state Available. A deployment created before private network access has an-edgestack inus-east-1instead (an IAM role, a Lambda function and a published version). - In Lambda (deployment region), filter functions by
alphaagent-env-. One per execution environment your users have created. - In S3, filter buckets by
alphaagent-. Seven from the stack plus the deploy bucket, and the optional staging bucket from the account template.
What you should see
The table below is generated from the templates and the deployment inventory; a build check regenerates it so it cannot drift from the fixture. Counts are per deployment.
| Stack | Resource type | Count | Purpose | Cost driver |
|---|---|---|---|---|
| core | AWS::EC2::VPC | 1 | Dedicated network for the deployment | No charge |
| core | AWS::EC2::Subnet | 4 | Two private subnets across two availability zones, in the range you chose; with AlphaAgent's NAT gateway also two public /28 subnets for it | No charge |
| core | AWS::EC2::RouteTable / Route / SubnetRouteTableAssociation / InternetGateway / VPCGatewayAttachment | 10 | Private routing; public routing and the internet gateway only with AlphaAgent's NAT gateway | No charge |
| core | AWS::EC2::NatGateway | 1 | Outbound internet for the private subnets, only with outbound traffic through AlphaAgent's NAT gateway | Hourly plus per GB processed |
| core | AWS::EC2::EIP | 1 | Address of the NAT gateway, only with the NAT gateway | Hourly while the NAT gateway exists |
| core | AWS::EC2::SecurityGroup | 5 | Load balancer, tasks, sandboxes, Redis, EFS | No charge |
| core | AWS::EC2::VPCEndpoint | 10 | Gateway: S3, DynamoDB. Interface: Secrets Manager, STS, ECR API, ECR registry, CloudWatch Logs, SQS, Systems Manager, Bedrock Runtime | Interface endpoints hourly per availability zone plus per GB; gateway endpoints no charge |
| core | AWS::DynamoDB::Table | 38 | Agents, environments, chat, workflows, runs and events, connectors, knowledge graphs, notifications, API keys, share requests, the metering outbox | On-demand reads and writes, storage; point-in-time recovery on 14 tables |
| core | AWS::S3::Bucket | 7 | workspaces, kb-artifacts, kb-processing, kb-dgl-training, chat-overflow, code-scripts, frontend | Storage per GB-month and requests; versioning keeps prior versions until a lifecycle rule expires them |
| core | AWS::SQS::Queue | 6 | Knowledge graph processing, notification events, workflow schedules, each with a dead-letter queue | Per million requests |
| core | AWS::SecretsManager::Secret | 19 | Per-service and common configuration, licence bootstrap and persisted secret, Neo4j credentials, PII hash key, trusted certificate authorities | Per secret per month plus API calls |
| core | AWS::ECR::Repository | 3 | alphaagent/studio (also the release's SearXNG and Neo4j images), alphaagent-envs, alphaagent/web-browser-search | Storage per GB-month |
| core | AWS::ElastiCache::ReplicationGroup | 1 | Sessions and runtime cache; at-rest and in-transit encryption | Node hours (default cache.t4g.medium) |
| core | AWS::EFS::FileSystem / MountTarget / AccessPoint | 5 | Neo4j data and logs, encrypted, elastic throughput, AWS Backup enabled | Storage per GB-month, throughput per GB, backup storage |
| core | AWS::Cognito::UserPool / UserPoolClient / UserPoolDomain | 3 | Studio sign-in, federated to your identity provider | Monthly active users above the free tier |
| core | AWS::IAM::Role | 2 | Sandbox Lambda execution role and sandbox scoped role | No charge |
| core | AWS::Events::Rule | 1 | kb-artifacts object-created to the processing queue | Per million events |
| core | AWS::SNS::Topic / Subscription | 2 | Notification events | Per million requests |
| core | AWS::SSM::Parameter | 2 | Deployment parameters | No charge |
| core | AWS::Logs::LogGroup | 10 | One per service; retention LogRetentionInDays, default 30 | Ingestion per GB, storage per GB-month |
| stateless | AWS::ElasticLoadBalancingV2::LoadBalancer | 1 | Internal, in the private subnets; HTTPS 443 with your certificate, 80 redirects to 443 (internet-facing only on deployments created before private network access) | Hourly plus LCU hours |
| stateless | AWS::ElasticLoadBalancingV2::Listener / ListenerRule / TargetGroup | 28 | Routing to the eleven services; authenticate-cognito on every rule except /api/v1; origin-lock header required behind CloudFront | No charge |
| stateless | AWS::EC2::SecurityGroup | 1 | Load balancer: HTTPS and HTTP from the VPC range | No charge |
| stateless | AWS::Lambda::Function | 1 | Serves the Studio web app (python3.12), with its role and permission | Per request and GB-second |
| stateless | AWS::CloudFront::Distribution | 1 | Only on deployments created before private network access: the front door, alias your app domain, TLS 1.2 minimum, adds the origin-lock header | Per request and per GB transferred, only when present |
| stateless | AWS::WAFv2::IPSet / WebACL / WebACLAssociation | 3 | Blocks /api/v1 from sources outside your allow-list; created only when ApiWafIpSetCidrs is set | Web ACL and rule per month plus per million requests, only when created |
| stateless | AWS::Logs::LogGroup | 1 | SPA server, 30 days | Ingestion and storage |
| private-network | AWS::EC2::Route | 1 per range | Each user access range and internal service range to your Transit Gateway; with Transit Gateway egress also 0.0.0.0/0, and the route that drops unlisted private ranges | No charge |
| private-network | AWS::EC2::SecurityGroupIngress | 2 per user range | HTTPS and HTTP from each user access range | No charge |
| private-network | AWS::EC2::SecurityGroupEgress | 1 per range and port | Agent code to each approved internal range on each approved port | No charge |
| private-network | AWS::EC2::VPCEndpoint / SecurityGroup | 7 | Lambda, EventBridge, SNS, CloudWatch, Bedrock, Session Manager messages, and their security group, only with outbound traffic through your Transit Gateway | Interface endpoints hourly per availability zone plus per GB, only when created |
| private-network | AWS::EC2::PrefixList / NetworkInterface / SecurityGroup | 3 | A prefix list of the private blocks and a never-attached network interface, so unlisted private ranges are dropped in the VPC | No charge |
| compute | AWS::ServiceDiscovery::HttpNamespace | 1 | Service Connect between tasks | No charge |
| compute | AWS::ECS::Cluster / ClusterCapacityProviderAssociations | 2 | The Fargate cluster | No charge for the cluster itself |
| compute | AWS::IAM::Role | 2 | Task execution role; task role with Bedrock invoke and Marketplace subscribe, and a deny on invoking any global. inference profile | No charge |
| taskdef | AWS::ECS::TaskDefinition | 12 | Eleven services plus the on-demand kg-transfer task; all ARM64 Fargate | No charge |
| taskdef | AWS::ECS::Service | 11 | The running services | Fargate vCPU-hours and GB-hours per the sizing profile |
| taskdef | AWS::CloudWatch::Alarm | 6 | Service health and metering alarms | Per alarm per month |
| taskdef | AWS::Logs::MetricFilter | 2 | Bedrock invocation counts | No charge |
| taskdef | AWS::Logs::LogGroup | 3 | kg-transfer, SearXNG, Neo4j; 30 days | Ingestion and storage |
| edge | AWS::IAM::Role | 1 | Lambda@Edge execution role | No charge |
| edge | AWS::Lambda::Function | 1 | Origin-response function attached to the distribution (nodejs24.x) | Per Lambda@Edge request and GB-second |
| edge | AWS::Lambda::Version | 1 | Published version the distribution references | No charge |
| account template | AWS::IAM::Role | 1 | AlphaAgentOrgTarget-<suffix>, assumable only by your Organisations account with the External ID | No charge |
| account template | AWS::IAM::ManagedPolicy | 4 | Guardrails, stacks and compute, data and storage, application and probe (plus WAF when enabled) | No charge |
| account template | AWS::S3::Bucket | 1 | alphaagent-org-staging-<account>-<region> for Library transfers; objects expire after 7 days | Storage per GB-month while a transfer is staged |
For what these cost at each sizing profile, see Infrastructure sizing and costs.
Limits
- A private deployment uses no other region: a service control policy may deny
us-east-1, CloudFront and Lambda@Edge. Only an existing public deployment's edge stack lives inus-east-1; see SCPs and guardrails. - One VPC per deployment counts against the account's quotas, and with the NAT gateway one NAT gateway and one Elastic IP; the Organisations preflight checks the headroom.
- The VPC range is fixed when the deployment is created; its two private subnets need room for what each release runs there, and an update checks that first.
- The Heavy tier tops out at 16 vCPU per task; larger profiles add memory only.
- Every image runs from your account's ECR, including the web search (SearXNG) and graph database (Neo4j, with APOC) images the release ships: nothing is pulled from a public registry at task start.
If something goes wrong
- A
-corestack resource is missing from your account: the deployment's job in the Organisations console names the failed step and the CloudFormation failure reason. See Jobs, progress and failures. - The app domain does not answer: check your private DNS record points at the internal load balancer, the zone is associated with the deployment's VPC, your address is in a user access range, and the Overview's Network check is healthy (Troubleshooting the install).
- An existing public deployment's load balancer answers 403 to every request: you are reaching it directly rather than through CloudFront. Point your DNS at the distribution.