Skip to main content

EC2 Instances

After the Phase 7 cleanup of 2026-05-14, Jitsi is the only EC2 instance left in the account. Every other backend / AI workload runs on ECS Fargate.

Instance Inventory​

NameInstance IDTypePublic IPEBSIAM ProfilePurpose
aiqlick-jitsii-0620d2e23695f5bfct3.xlarge16.16.21.6420GB gp3EC2-SSM-ProfileJitsi Meet (UDP, can't move to Fargate)

Sizing​

  • Jitsi (t3.xlarge): 4 vCPU, 16GB RAM. Video conferencing needs the memory for JVB + Jigasi transcription. Supports up to 25 participants per meeting.

Why Jitsi stays on EC2​

The JVB media bridge needs UDP :10000 and Jigasi needs :20000-20050/UDP for transcription audio. Fargate doesn't support UDP listeners, so the Jitsi stack would need a different orchestrator (or remain on EC2). At the current scale (one prod instance, ≤25 participants) staying on EC2 is the right tradeoff.

Jitsi runs Nginx + a Docker Compose stack (web, prosody, jicofo, jvb, jigasi) inside the t3.xlarge. The stack is managed via the jitsi-deploy/ repo. SSL termination uses Nginx + Let's Encrypt (separate from the ECS cluster's ACM cert).

Security Group​

SGProtocolPortSourcePurpose
jitsi-sgTCP220.0.0.0/0SSH access
TCP800.0.0.0/0HTTP redirect
TCP4430.0.0.0/0HTTPS (Jitsi web UI + signaling)
UDP100000.0.0.0/0JVB media (WebRTC)
UDP20000-200500.0.0.0/0Jigasi RTP (transcription audio)

IAM (EC2-SSM-Profile)​

Minimal — just AmazonSSMManagedInstanceCore for remote management. Jitsi doesn't talk to AWS services directly; transcription goes through background-tasks → Transcribe.

Operational commands​

# SSH (preserved for Jitsi only)
ssh jitsi

# Status
docker ps --filter "name=jitsi"

# Logs
docker logs -f jitsi-jvb-1
sudo journalctl -u nginx -n 100

Decommissioned (Phase 7 cleanup, 2026-05-14)​

The four backend / AI EC2 hosts that previously served the platform were terminated as part of the Phase 7 cleanup on 2026-05-14T17:33 UTC. They lived at:

NameInstance IDTypeEIP (released)
aiqlick-backendi-0b9f31f3236c25b7ft3.small13.62.166.68
aiqlick-aii-053ddc2f75899c06at3.small51.21.229.163
aiqlick-backend-devi-0b7d632f4de8a5a9at3.micro13.62.32.225
aiqlick-ai-devi-0912ca82a42fd6ba4t3.small13.63.47.99

These names appear in older runbooks and ticket history; they no longer exist in the AWS account. The IAM profiles + roles (aiqlick-{backend,ai}-ec2-profile, aiqlick-{backend,ai}-ec2-role), all 9 custom policies (aiqlick-backend-{s3-secrets,events,appconfig,inbound,mail}-policy, aiqlick-background-tasks-policy, aiqlick-ai-{bg-events,events,inbound}-policy), and the legacy security groups (aiqlick-backend-sg, aiqlick-ai-dev-private-sg) were also deleted in the same window.

DNS cleanup (done 2026-05-14)​

The ai.aiqlick.com and ai-dev.aiqlick.com records were deleted from the one.com control panel by the operator on the same day. Both hostnames now resolve to one.com's parking IP 46.30.213.40 (the default response for any unconfigured subdomain on a one.com-hosted zone), which serves an Apache 500 — see Network → *.aiqlick.com returns a 500 from a non-AWS IP. The pointer at AWS-released EIPs is gone; subdomain-takeover risk is closed.

Frontend never called these hostnames anyway (the AI gateway on api(.dev).aiqlick.com is the only path to BG).

GitHub Actions self-hosted runner (decommissioned)​

The shared aiqlick-gha-runner instance (i-0b13fda708cf21e54, t3.medium) referenced in older docs has been terminated. All workflows now run on GitHub-hosted ubuntu-latest runners. ECS deploys are fast enough on hosted runners (image build + push + RegisterTaskDefinition + UpdateService is ~3 minutes total) that the self-hosted runner's deploy-speed advantage no longer justified the maintenance burden.

The historical write-up of why the self-hosted runner existed is kept at self-hosted-runner.md for context.