AETHER architecture & dependencies

AETHER is a set of .NET services orchestrated with .NET Aspire. Clients deploy the pre-built container images and connect them to managed data services.

Components

Component	Role	Public?
Agent.Web	Management platform, admin UI, SignalR chat	Yes (ALB/ingress)
Agent.Service	Chat orchestration, Semantic Kernel, multi-agent	Internal
Agent.API	Public REST API for agents	Yes
Agent.Worker	Async jobs via RabbitMQ (Python, images, artifacts)	Internal
MCP servers	Tool servers (DMS, UMS, …)	Internal

Dependency matrix (recommended managed services)

Concern	AWS	Azure	GCP
Containers	ECS Fargate	Container Apps	Cloud Run
Registry	ECR	ACR	Artifact Registry
PostgreSQL + pgvector	RDS	Flexible Server	Cloud SQL
Redis (cache + backplane)	ElastiCache	Cache for Redis	Memorystore
Object storage (S3 API)	S3	MinIO container	GCS (interop)
Queue (RabbitMQ)	Amazon MQ	CloudAMQP	CloudAMQP
Secrets	Secrets Manager	Key Vault	Secret Manager

Three things teams get wrong

Object storage must speak S3

AETHER uses the MinIO/S3 SDK. S3 (AWS) and GCS interop (GCP) work natively; Azure Blob does not — run a MinIO container on Azure.

The queue is RabbitMQ

The Worker uses the MassTransit RabbitMQ transport. Only AWS has managed RabbitMQ (Amazon MQ); Azure/GCP use CloudAMQP or a RabbitMQ container. SQS/Service Bus/Pub-Sub would require rebuilding.

pgvector must be allow-listed

Enable pgvector before initializing the DB: RDS rds.allowed_extensions, Azure azure.extensions=VECTOR, Cloud SQL cloudsql.enable_pgvector=on.

Scaling to thousands of conversations

SignalR runs on a Redis backplane — scale Agent.Web/Agent.Service horizontally behind a WebSocket-capable, sticky ingress.
Scale Agent.Worker on RabbitMQ queue depth.
Use Postgres connection pooling (RDS Proxy / PgBouncer) — EF Core × many replicas exhausts connections fast.
Size Redis for cache + backplane combined; mind OpenAI rate limits.