Cost Overview
AIQLick's AWS infrastructure runs in eu-north-1 (Stockholm) with a small footprint optimized for an early-stage platform. This page breaks down the monthly cost structure and documents the optimization strategies in place.
Monthly Cost Breakdown
Compute (EC2)
| Instance | Type | vCPU | RAM | Approx. Cost/mo |
|---|---|---|---|---|
| aiqlick-backend | t3.small | 2 | 2GB | ~$15 |
| aiqlick-ai | t3.small | 2 | 2GB | ~$15 |
| aiqlick-backend-dev | t3.micro | 2 | 1GB | ~$7.50 |
| aiqlick-ai-dev | t3.micro | 2 | 1GB | ~$7.50 |
| aiqlick-jitsi | t3.xlarge | 4 | 16GB | ~$60 |
| EC2 Subtotal | ~$105/mo |
Prices are approximate on-demand rates for eu-north-1. Actual costs may vary slightly based on data transfer and EBS usage.
Database (RDS)
| Instance | Class | Engine | Storage | Approx. Cost/mo |
|---|---|---|---|---|
| aiqlick-postgres | db.t4g.small | PostgreSQL 16.6 | 50GB gp3 | ~$25 |
| aiqlick-postgres-dev | db.t4g.micro | PostgreSQL 16.10 | 20GB gp3 | ~$13 |
| Storage (gp3, 70GB total) | ~$8 | |||
| Automated backups | ~$4 | |||
| RDS Subtotal | ~$50/mo |
Storage & CDN
| Service | Details | Approx. Cost/mo |
|---|---|---|
| S3 | 6 buckets (uploads, dev-uploads, backups, deployments, docs, docs-dev) | ~$5 |
| CloudFront | 4 distributions (storage + docs, prod + dev), PriceClass_100 | ~$5-10 |
| Storage Subtotal | ~$10-15/mo |
Container Registry (ECR)
| Repository | Image Size | Approx. Cost/mo |
|---|---|---|
| aiqlick-backend | ~240MB | ~$1 |
| background-tasks | ~699MB | ~$2 |
| aiqlick-meeting | ~142MB | ~$0.50 |
| aiqlick-jigasi | ~505MB | ~$1.50 |
| ECR Subtotal | ~$5/mo |
AI Services (Bedrock)
| Model | Pricing Model | Cost Driver |
|---|---|---|
| Claude (Anthropic) | Per input/output token | Agent chat, text rewrite, meeting insights |
| Titan Embed v2 | Per input token | RAG document/query embedding |
Bedrock costs are pay-per-token and scale directly with platform usage. At low usage, costs are minimal ($5-20/mo). At scale, this becomes the dominant cost category.
All Bedrock token consumption is tracked in the AIOperationLog table with input/output token counts and mapped credit costs. The credit system charges users at configurable rates per model via CreditCostConfig.
Other Services
| Service | Details | Approx. Cost/mo |
|---|---|---|
| Amplify | Build minutes + Next.js SSR hosting (dev + prod branches) | ~$10-20 |
| Secrets Manager | 3 secrets at $0.40/secret/month | ~$1.20 |
| Rekognition | DetectFaces API calls (per-image pricing) | ~$1-5 |
| Transcribe | Real-time streaming (per-second pricing) — meetings + voice STT | ~$2-10 |
| Polly Neural | Text-to-speech for voice chat ($16/1M chars) | ~$1-5 |
| CloudWatch | Logs and basic monitoring | ~$2-5 |
| Data Transfer | Inter-region + internet egress | ~$5-10 |
| Other Subtotal | ~$25-55/mo |
Total Infrastructure Cost
| Category | Monthly Range |
|---|---|
| EC2 | ~$105 |
| RDS | ~$50 |
| S3 + CloudFront | ~$10-15 |
| ECR | ~$5 |
| Amplify | ~$10-20 |
| Other (Secrets, CloudWatch, Transfer) | ~$10-20 |
| Total (excluding Bedrock) | ~$180-200/mo |
| Bedrock (usage-dependent) | $5-100+/mo |
Current Optimization Strategies
The infrastructure is designed for cost efficiency at the current stage of the platform.
Burstable Instances (t3 Family)
All EC2 instances use t3 burstable instances, which accumulate CPU credits during idle periods and spend them during load spikes. This is significantly cheaper than fixed-performance instances for workloads with variable CPU demand.
| Instance Type | On-Demand | Equivalent Fixed (m5) | Savings |
|---|---|---|---|
| t3.micro | ~$7.50/mo | ~$35/mo (m5.large min) | ~78% |
| t3.small | ~$15/mo | ~$35/mo (m5.large min) | ~57% |
| t3.xlarge | ~$60/mo | ~$70/mo (m5.xlarge) | ~14% |
Tiered Dev Environments
Development instances use smaller (and cheaper) instance classes than production:
- EC2: t3.micro (dev) vs t3.small (prod) -- 50% cost reduction
- RDS: db.t4g.micro (dev) vs db.t4g.small (prod) -- ~48% cost reduction
- EBS: 8GB (dev) vs 20-30GB (prod) -- smaller disk allocations
CloudFront PriceClass_100
Both CloudFront distributions use PriceClass_100, which limits edge locations to the cheapest regions (North America and Europe). This is appropriate since the primary user base is in the Nordics and Europe.
Single-AZ RDS
Both RDS instances run in a single Availability Zone without Multi-AZ failover. This halves the RDS compute cost. For the current stage of the platform, the trade-off of slightly higher downtime risk during AZ failures is acceptable.
External Redis
Redis Cloud is used instead of Amazon ElastiCache. A small external Redis instance is cheaper than the minimum ElastiCache node (cache.t4g.micro at ~$12/mo) and requires no VPC configuration overhead.
No NAT Gateway
EC2 instances have public IPs and route directly to the internet, avoiding the ~$32/mo fixed cost of a NAT Gateway per AZ.
Minimal EBS Storage
EBS volumes use gp3 (the cheapest general-purpose SSD tier) with conservative sizing:
| Instance | EBS Size | Rationale |
|---|---|---|
| Backend (prod) | 20GB | Docker images + logs |
| AI (prod) | 30GB | Larger ML-related images |
| Dev instances | 8GB | Minimal footprint |
| Jitsi | 20GB | Docker Compose services (6 containers) |
Future Optimization Options
As the platform scales, several cost optimization strategies become worthwhile:
Reserved Instances / Savings Plans
For instances running 24/7, Reserved Instances or Compute Savings Plans offer 30-40% savings over on-demand pricing.
| Option | Commitment | Typical Savings |
|---|---|---|
| 1-year Reserved Instance (no upfront) | 1 year | ~30% |
| 1-year Reserved Instance (all upfront) | 1 year | ~38% |
| 3-year Reserved Instance (all upfront) | 3 years | ~55% |
| Compute Savings Plan | 1-3 years | ~30-50% |
Compute Savings Plans are more flexible than Reserved Instances because they apply across instance families, sizes, and regions. They are the recommended option once instance usage patterns stabilize.
ECR Lifecycle Policies
ECR currently retains all image tags indefinitely. Adding lifecycle policies to automatically expire old images would reduce storage costs and keep repositories clean.
{
"rules": [
{
"rulePriority": 1,
"description": "Keep only last 10 images",
"selection": {
"tagStatus": "any",
"countType": "imageCountMoreThan",
"countNumber": 10
},
"action": {
"type": "expire"
}
}
]
}
Graviton (ARM) Instances
AWS Graviton processors (ARM-based) offer approximately 20% better price-performance than equivalent x86 instances. Both the backend (Node.js) and background-tasks (Python) workloads are compatible with ARM.
| Current | Graviton Equivalent | Savings |
|---|---|---|
| t3.small (x86) | t4g.small (ARM) | ~20% |
| t3.micro (x86) | t4g.micro (ARM) | ~20% |
| t3.xlarge (x86) | t4g.xlarge (ARM) | ~20% |
The RDS instances already use Graviton (db.t4g family). EC2 instances are the remaining migration target.
ALB + Auto Scaling
Currently, each service runs as a single Docker container on a single EC2 instance. When traffic justifies it, moving to an Application Load Balancer with Auto Scaling Groups would provide:
- Automatic horizontal scaling based on CPU/memory thresholds
- Health-check-based instance replacement
- Zero-downtime deployments via rolling updates
- Multi-AZ redundancy
The trade-off is added complexity and the base cost of an ALB (~$16/mo + per-request charges).
RDS Multi-AZ
Enabling Multi-AZ on the production RDS instance would provide automatic failover to a standby replica in another Availability Zone. This doubles the RDS compute cost but provides higher availability for production workloads.
Spot Instances for Dev
Development EC2 instances could run on Spot pricing for up to 90% savings. The trade-off is that AWS can reclaim the instance with 2 minutes notice, which is acceptable for non-production environments.
Bedrock Cost Management
Bedrock (LLM inference) is the only usage-based cost that scales with platform activity. The platform tracks and manages these costs through several mechanisms:
Cost Tracking
Every AI operation is logged in the AIOperationLog table with:
- Model ID and operation type (CV_EXTRACTION, JOB_PARSING, MATCHING, AGENT_CHAT, etc.)
- Input and output token counts
- Calculated credit cost based on
CreditCostConfigrates
Credit System Mapping
Users pay for AI operations through the credit system:
- 1 credit = $1 of token consumption
- Credit costs are configurable per model via the
CreditCostConfigadmin table - The
BillingGatein background-tasks performs a pre-check before each AI operation and deducts credits after completion - Failed operations are not charged
Cost Control Mechanisms
| Mechanism | Description |
|---|---|
| Credit balance limits | Users cannot exceed their purchased or allocated credits |
| Plan-based allocation | Each subscription plan includes a monthly credit allocation |
BillingGate pre-check | Rejects operations when balance is insufficient |
BILLING_ENABLED env var | Gradual rollout of billing enforcement |
| Per-company config | CompanyBillingConfig allows per-company credit allocation overrides |
Monitoring
# Check Bedrock invocation metrics
aws cloudwatch get-metric-statistics \
--profile Administrator-842697652860 \
--region eu-north-1 \
--namespace AWS/Bedrock \
--metric-name Invocations \
--start-time $(date -u -v-7d +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 86400 \
--statistics Sum \
--output table