The Trinity Beast Infrastructure — Resource Inventory

Complete inventory of all AWS resources, their purpose, specifications, and interconnections. Source of truth for all infrastructure documentation.

Account: 211998422884 Region: us-east-2 (Ohio) Updated: October 10, 2026 Version: v19

Infrastructure Summary
AWS Services & Components
Compute Layer — ECS Fargate
Data Layer
Network Layer
Content Delivery & Storage
Scheduled Tasks & Automation
AI & Translation Services
Autonomous Operations (AutoOps)
Secrets & Security
CloudWatch Dashboards & Alarms
Price Feed Architecture
Performance Configuration
Stress Test Resources
Connection Map

1. Infrastructure Summary

ECS Services

3 LPO/LRS + 1 Webhook + 1 Translate

Total vCPU (baseline)

2 each × 5 services

Total RAM (baseline)

30 GB

6 GB each × 5 services

Aurora ACU

1.5–18

Serverless v2

ElastiCache

Serverless

Valkey 9.0 · Multi-AZ

DB Connections

600

150 per container

Load Balancers

1 ALB + 1 NLB

Availability Zones

1 container per AZ

AWS Services & Components in Use

Every service powering The Trinity Beast — grouped by function. Hover any tile to highlight.

Compute & Containers

Amazon ECS

Container orchestration

AWS Fargate

Serverless containers

Amazon ECR

Container registry

AWS Lambda

Receipts · AutoOps

Step Functions

Translation orchestration

Database & Cache

Amazon Aurora

PostgreSQL Serverless v2

ElastiCache

Valkey 9.0 · Serverless

Amazon RDS

Managed databases

Networking & Content Delivery

Amazon VPC

Private network

Route 53

DNS

ALB + NLB

TCP & UDP load balancing

CloudFront

Global CDN

Messaging & Eventing

Amazon SQS

Fire-and-forget writes

Amazon SNS

Notification fan-out

EventBridge

Schedules & events

Amazon SES

Transactional email

Storage

Amazon S3

Website · Documents · Backups

AI / ML

Amazon Bedrock

Qwen 3 235B · AutoOps · Translate

Amazon Translate

Inline translations

Security, Identity & Compliance

AWS IAM

Roles & policies

Secrets Manager

Credentials vault

AWS KMS

Encryption keys

AWS ACM

TLS certificates

AWS WAF

Layer 7 firewall

AWS Shield

DDoS protection

GuardDuty

Threat detection

CloudTrail

API audit log

Management & Governance

CloudWatch

Dashboards · Alarms · Logs

CloudFormation

Infrastructure as code

Systems Manager

Operations & ECS Exec

Application Layer

WebSocket Feeds

6 exchanges · real-time

UDP v8 Protocol

487K RPS · 0.2 ms

Prewarmed Cache

360 assets always hot

Exchange Manager

Table-driven config

Tier Rate Limits

5 public + partner

App Parameters

Runtime config

Runtime Metrics

24 atomic counters

Webhook Engine

Push delivery · UDP+HTTPS

LRS Analytics

4 reports · 4 formats

Customer Dashboard

Self-service portal

Command Centers

KCC & TBCC

Document Library

Technical docs

12 Languages

Full i18n coverage

Third-Party Integrations

Stripe

Subscriptions & receipts

2. Compute Layer — ECS Fargate

Cluster: trinity-beast-fargate-cluster — 5 services. The first 3 run the same Docker image (trinity-beast-lpo-server:latest) with APP_REPORT_SERVER (LPO + LRS). The 4th runs WEBHOOK_SERVER (outbound price push delivery). The 5th is BeastTranslate — a Python container that polls the translation SQS queue with demand-driven auto-scaling (1→11 containers). All tasks run on AWS Nitro System hosts — Nitro Cards offload networking and storage I/O to dedicated hardware, delivering bare-metal-equivalent performance and hardware-enforced security isolation.

Service	Task Definition	SERVER_TYPE	vCPU	RAM	DB Conns	Cache Conns	Ports
`trinity-beast-main-service`	lpo-task:23	`APP_REPORT_SERVER`	2 vCPU	6 GB	150	300	TCP 8080, 9090 / UDP 2679, 2680
`trinity-beast-mirror-service`	lpo-task:23	`APP_REPORT_SERVER`	2 vCPU	6 GB	150	300	TCP 8080, 9090 / UDP 2679, 2680
`trinity-beast-lrs-service`	lpo-task:23	`APP_REPORT_SERVER`	2 vCPU	6 GB	150	300	TCP 8080, 9090 / UDP 2679, 2680
`trinity-beast-webhook-service`	webhook-task:6	`WEBHOOK_SERVER`	2 vCPU	6 GB	150	300	TCP 8083 (health only)
`tbi-translate-worker-service`	tbi-translate-worker-task	— (Python)	2 vCPU	6 GB	—	—	None (SQS poller)

Key Features per Container: Independent WebSocket price feeds (6 exchanges), local sync.Map cache (zero-network hot path), Distributed Adaptive Connection Governor (6000 max concurrent), blocking UDP governor, micro-batch Aurora writes (300 rows / 100ms trickle), structured JSON error responses.

Webhook Service (BeastWebhook): Reads active webhook_subscriptions from Aurora, resolves prices from local wsPriceCache (same 6 WebSocket feeds), and pushes to Associates via UDP fire-and-forget + HTTPS signed POST with 3 retries. Health check on TCP 8083. CLUSTER_NODE: BeastWebhook. Sized at 2 vCPU / 6 GB to match other services for operational consistency.

Corrected 2026-08-12 — no longer outbound-only. Since 2026-08-07 the same container also serves a real, health-checked inbound test-receiver surface: HTTPS on port 8090 (behind the ALB, host-header webhook.cpmp-site.org, target group trinity-beast-webhook-test-tg) and UDP on port 2681 (behind the UDP NLB, target group Trinity-Beast-UDP-2681-TG), with a dedicated health server on port 8092 serving both. This exists to test both transports of the webhook engine's own outbound delivery against a real network endpoint — first for internal verification, later planned for tech-support use testing a customer's own feed — and is allow-listed and rate-limited rather than open to arbitrary callers. See Trinity-Beast-Kiro-Command-Center.html § Webhook Push Test Receiver for the full design and Trinity-Beast-CloudWatch-Guide.html for its two target-group health alarms.

Peak Utilization (Run 15 Stress Test): Main: 96.3% CPU / 92.7% Memory | Mirror: 97.0% CPU / 96.9% Memory | LRS: 80.1% CPU / 73.2% Memory. All containers survived 21.4M requests across all 13 stress levels.

Translation Worker (BeastTranslate): Persistent ECS Fargate service that polls the trinity-beast-translation-queue SQS queue. Auto-scales from 1 (idle) to 11 containers (one per target language) on job submission, then scales back to 1 when the queue empties. Each container runs Python 3.11 with the Qwen3-235B model via Bedrock. Also polls for completed batch inference jobs every 33s during idle. ECR image: tbi-translate-worker:latest. CLUSTER_NODE: BeastTranslate.

Right-Sized (2026-05-30, updated 2026-08-03): All ECS services (main, mirror, LRS, webhook, translate) run at 2 vCPU / 6 GB. Sustained utilization at current traffic is 3–5% CPU — massive headroom. Horizontal auto-scaling (min 1, max 3, target CPU 60%) handles load spikes by adding containers. The 4 vCPU / 16 GB profile is the step-up size; 8 vCPU / 32 GB (battle-tested under Run 17: 746K RPS) is the ceiling for extreme load.

Lambda

Function	Purpose	Runtime	Memory	Timeout	Architecture	Connects To
`trinity-beast-receipt`	Post-checkout receipt processing (subscription, donation, LRS addon, webhook) and Stripe webhook handling (tier changes, cancellations, payment failures, refunds). Uses admin API for all DB access (zero direct DB). Assembles localized emails from Valkey frames. Enqueues emails to SQS for async delivery.	provided.al2023 (Go)	`1770` MB	`180s`	`x86_64`	Stripe API, Valkey, SQS (`trinity-beast-email-queue`), api.cpmp-site.org/admin
`trinity-beast-email-sender`	Brainless SQS consumer — receives pre-built email messages and delivers via SES. No DB, no Valkey, no Bedrock. Batch size 6, 3-second batching window, `ReportBatchItemFailures`.	provided.al2023 (Go)	`1770` MB	`60s`	`x86_64`	SES

Note: Neither Lambda is in the VPC. The receipt Lambda uses the admin API (api.cpmp-site.org/admin/sql) for all DB operations and /admin/invalidate-key for cache invalidation — avoids $32/mo NAT gateway. Secret: trinity-beast-receipt-secrets (Stripe keys only). The email-sender Lambda only needs SES (public).

SQS — Usage Log Queue

Attribute	Value
Queue Name	`trinity-beast-queued-usage-logs`
Type	Standard (not FIFO)
Message Retention	4 days
Visibility Timeout	60 seconds
Purpose	Decouples usage log writes from the price hot path. LPO server sends fire-and-forget messages to SQS; the `trinity-beast-queued-writer` Lambda consumes batches and batch-inserts into Aurora.
Consumer	`trinity-beast-queued-writer` Lambda (Go, provided.al2023, 1770 MB)
Event Source Mapping	Batch size `100`, max batching window 5 seconds

Architecture: The SQS queue eliminates Aurora write pressure from the price hot path. The LPO server publishes usage log messages to SQS with fire-and-forget semantics. The trinity-beast-queued-writer Lambda polls the queue in batches of 100 (with a 5-second batching window) and performs efficient batch inserts into Aurora. At normal production traffic, SQS cost is ~$1.00/month ($0.40 per million messages).

SQS — Email Queue

Attribute	Value
Queue Name	`trinity-beast-email-queue`
Queue URL	`https://sqs.us-east-2.amazonaws.com/211998422884/trinity-beast-email-queue`
Purpose	Async email delivery — decouples receipt Lambda from SES latency
Message Format	JSON: `{to, subject, html_body, lang, timestamp}`
Visibility Timeout	60 seconds
Message Retention	4 days (345,600s)
Encryption	SQS-managed (SSE-SQS)
Consumer	`trinity-beast-email-sender` Lambda (Go, provided.al2023, 1770 MB)
Event Source Mapping	Batch size 6, max batching window 3 seconds, `ReportBatchItemFailures`

Architecture: The receipt Lambda builds complete localized emails from pre-translated Valkey frames, then enqueues the finished message (~20 ms). The trinity-beast-email-sender Lambda picks up batches every 3 seconds and delivers via SES. Customer receives their email within 3–6 seconds of checkout. If SQS fails, the receipt Lambda falls back to direct SES delivery.

3. Data Layer

Aurora Serverless v2 Available

Attribute	Value
Cluster	`trinity-beast-aurora-cluster`
Engine	PostgreSQL 17.7
ACU Range	1.5 – 18 (auto-scaling)
Storage	Optimized I/O (aurora-iopt1)
Writer	`trinity-beast-aurora-writer` (us-east-2c)
Reader	`trinity-beast-aurora-reader` (us-east-2b)
Writer Endpoint	`trinity-beast-aurora-cluster.cluster-cvg4oeysemon.us-east-2.rds.amazonaws.com`
Reader Endpoint	`trinity-beast-aurora-cluster.cluster-ro-cvg4oeysemon.us-east-2.rds.amazonaws.com`
Total Connections	600 (`150` per container × 4)
Deletion Protection	Enabled
Peak ACU (Run 15)	16.5 of 18 max

Tables (~59 in the public schema — the live database is authoritative; representative key tables by domain below):

Identity & billing: users, api_keys, api_key_groups, rate_limit_template, tier_catalog, tier_change_history, transactions, payment_links, stripe_customer_xref
Usage & reporting: usage_logs, report_usage_logs, report_count, monthly_report_counts, report_parameters, page_views, page_events
Price feeds: exchange_asset_map, exchange_feeds, asset_categories, asset_symbol_renames, application_parameters
Webhook push: webhook_subscriptions, webhook_delivery_log, webhook_delivery_daily, webhook_test_receiver_allowlist
Translation (TBTS): translation_jobs, translation_tasks, translation_quotes, translation_job_events, translation_parameters, translation_supported_languages
Support (Rhema): support_tickets, support_replies, support_threads, support_thread_messages, dashboard_notifications
Agents, ops & content: agent_profiles, bedrock_model_catalog, kiro_decisions, email_templates, email_senders, newsletters, newsletter_subscribers, partner_applications, demo_leads, map_pins

ElastiCache Serverless for Valkey Available

Attribute	Value
Cache Name	`trinity-beast-cache-serverless`
Deployment	Serverless (auto-scaling, zero capacity planning)
Engine	Valkey 9.0
Availability	Multi-AZ (3 AZs, 99.99% SLA)
Data Storage Limit	30 GB (configurable max)
Compute Limit	10,000 ECPU/second (configurable max)
TLS (transit)	Always enabled (mandatory for Serverless)
Encryption at Rest	Always enabled (AWS-managed key)
Cluster Mode	Enabled (transparent via proxy — client connects as standalone)
Endpoint	`trinity-beast-cache-serverless-ptsbmm.serverless.use2.cache.amazonaws.com:6379`
Reader Endpoint	`trinity-beast-cache-serverless-ptsbmm.serverless.use2.cache.amazonaws.com:6380`
VPC	ECS VPC (`vpc-03deaddb7083cd59c`)
Security Group	`sg-08a14f22df269a909` (Trinity-Beast-Valkey-SG)
Pricing	Pay-per-use: ~$0.094/GB-hr storage + ~$0.0034/million ECPUs
Estimated Monthly	~$89 (at current workload: ~0.43 GB data, ~4.6M ECPUs/24h)

Key Patterns: apikey:{key} (API key hashes), price:{ASSET} (cached prices), usage_logs:index (sorted set), app:config (application parameters), {adaptive:lpo}:successes/total/throttle (governor counters), report_usage:{id} (report usage logs)

Migration History: Replaced node-based cache.r7g.2xlarge (Valkey 7.2, 52 GB, single node) on July 2, 2026. Zero code changes — the go-redis/v9 UniversalClient works unchanged with the Serverless proxy layer. Previously replaced MemoryDB (April 2026). Cost reduction: ~$628/mo node-based → ~$89/mo Serverless (about 86% savings). Aurora is the source of truth — ElastiCache is a pure performance cache rebuilt by the sync job in seconds.

4. Network Layer

Application Load Balancer Active

Attribute	Value
Name	`Trinity-Beast-TCP-ALB`
Type	Application (Layer 7)
Scheme	Internet-facing
Idle Timeout	`300` seconds
Cross-Zone	Enabled
Availability Zones	us-east-2a, us-east-2b, us-east-2c
`TLS`	ACM certificate, TLS 1.2+
Target Group (LPO)	`trinity-beast-fargate-group` → port 8080 (HTTP/1.1)
Target Group (LRS)	`trinity-beast-lrs-9090` → port 9090 (HTTP/1.1)
Target Group (Webhook Test Receiver)	`trinity-beast-webhook-test-tg` → port 8090 (HTTP/1.1), reached via a host-header rule for `webhook.cpmp-site.org`, added 2026-08-07
Deregistration Delay	30 seconds
Peak Throughput (Run 15)	31K req/s through ALB with TLS

Listeners: HTTPS:443 (default → LPO TG, rules: lrs.cpmp-site.org → LRS TG, /reports/* → LRS TG), HTTP:80, HTTP:8080, HTTP:9090

Network Load Balancer — UDP Active

Attribute	Value
Name	`Trinity-Beast-UDP-NLB`
Type	Network (Layer 4)
Scheme	Internet-facing
Protocol	`UDP`
Target Groups	`Trinity-Beast-UDP-2679-TG` (LPO), `Trinity-Beast-UDP-2680-TG` (LRS), `Trinity-Beast-UDP-2681-TG` (Webhook Test Receiver, added 2026-08-07)
Peak Throughput (Run 15)	84.9K UDP req/s through NLB

Route: udp.cpmp-site.org → UDP 2679 (LPO) / 2680 (LRS) / 2681 (Webhook Push Test Receiver, added 2026-08-07)

DNS (Route 53)

Record	Target	Purpose
`api.cpmp-site.org`	ALB (Trinity-Beast-TCP-ALB)	TCP API — LPO price queries
`lrs.cpmp-site.org`	ALB (Trinity-Beast-TCP-ALB)	TCP API — LRS reports
`udp.cpmp-site.org`	NLB (Trinity-Beast-UDP-NLB)	UDP API — LPO + LRS
`cpmp-site.org`	CloudFront (E110PRKEIYQVLL)	Website
`www.cpmp-site.org`	CloudFront (E110PRKEIYQVLL)	Website (www redirect)

VPC

Attribute	Value
VPC ID	`vpc-03deaddb7083cd59c`
`CIDR`	`10.0.0.0/16`
Subnets	Public (ALB/NLB) + Private (ECS, Aurora, ElastiCache)
Availability Zones	us-east-2a, us-east-2b, us-east-2c
ECS Subnet (current)	Main: `subnet-06781ce7266a4b870` (us-east-2a) · Mirror: `subnet-0e7e032219e0a6956` (us-east-2b) · LRS: `subnet-0d77afcde34842b5c` (us-east-2c)

Security Groups

Security Group	ID	Purpose
Trinity-ECS-SG-v3	`sg-050b617f93b2388f6`	ECS Fargate tasks — allows ALB/NLB + direct access
ElastiCache SG	`sg-08a14f22df269a909`	ElastiCache — allows ECS containers on port 6379
Stress Test SG	`sg-0bec9c9fa46fb3be1`	Stress test EC2 instances — allows SSM + container access

5. Content Delivery & Storage

CloudFront Distribution Deployed

Attribute	Value
Distribution ID	`E110PRKEIYQVLL`
Price Class	PriceClass_All (global edge locations)
Origin	S3 (trinity-beast-website-east2)
Custom Domains	`cpmp-site.org`, `www.cpmp-site.org`

S3 Bucket Active

Attribute	Value
Bucket	`trinity-beast-website-east2`
Purpose	Static website, documentation library, admin tools, stress test binaries
Key Paths	`/` (HTML), `/css/`, `/js/`, `/images/`, `/icons/`, `/docs/`, `/admin/`, `/tools/`, `/includes/`

ECR Repositories Active

Repository	Purpose
`trinity-beast-lpo-server`	Unified server image (all 4 ECS services including webhook)
`trinity-beast-sync-job`	Nightly sync job image

6. Scheduled Tasks & Automation

Rule	Schedule	Task Definition	Purpose	Status
`trinity-beast-nightly-sync`	`cron(0 6 * * ? *)` = 1 AM EST	trinity-beast-sync-job:3	Nightly Aurora → ElastiCache sync (`usage_logs`, `api_keys`, app params, `report_usage_logs`)	Enabled

Sync Performance: Full historical load of 249K logs completes in ~16 seconds. Incremental syncs (new records only) complete in under 200ms. The sync job uses redis.NewUniversalClient which works with both ElastiCache standalone and cluster mode configurations.

6b. AI & Translation Services

Amazon Translate Active

Attribute	Value
Service	Amazon Translate (Real-Time Translation API)
Region	`us-east-2`
Languages Supported	12 (en, es, pt, fr, de, ru, hi, ur, it, ar, ja, zh)
Integration Point	ECS containers (support handler)
Authentication	IAM Task Role (ECS task execution role)
Pricing	$15 per million characters
Estimated Monthly Cost	< $1.00 (support ticket volume)

Purpose: Language is not a barrier. When a customer submits a support ticket in any of the 12 supported languages, AWS Translate automatically converts their message to English for admin review. When the admin replies in English, the reply is translated to the customer's preferred language before the email is sent. Both original and translated versions are stored in Aurora for audit trail. The website UI is served in 12 languages via static JSON files — AWS Translate handles the dynamic, per-message translation layer.

Translation Flow

Direction	Trigger	Source	Target	Storage
Inbound	Customer submits ticket (lang ≠ en)	Customer's language	English	`support_tickets.message_en`
Outbound	Admin replies to ticket (lang ≠ en)	English	Customer's language	`support_replies.message_translated`
Map Captions	User taps pin (lang ≠ en) via `POST /translate`	English	User's language	ElastiCache `translate:{lang}:{hash}` (30-day TTL)

AutoOps Translation Engine (Custom Bedrock-Powered) Active

Attribute	Value
Service	Custom-built document translation engine powered by Amazon Bedrock. Standing model: Qwen 3 235B (`qwen.qwen3-235b-a22b-2507-v1:0`). The engine is model-configurable via the `agent_profiles` registry; Claude Opus is available as a premium option for customer translation jobs.
Region	`us-east-2`
Languages Supported	Our own document library: 11 target languages (es, pt, fr, de, ru, hi, ur, it, ar, ja, zh). Customer translation jobs: the 127-language catalog (`translation_language_catalog`, served live by `GET /translate/languages`).
Worker	ECS Fargate service (`tbi-translate-worker-service`, Python 3.11, 2 vCPU / 6 GB)
Scaling	Deterministic — Go code scales workers to `len(langs)` at submission, scales back to 1 when queue empties. No CloudWatch alarms or timers.
Orchestration	Task-based: `translation_tasks` → `translation_jobs` (1 per doc×lang pair) → SQS queue → workers
Queue	SQS (`trinity-beast-translation-queue`) — workers long-poll directly
CloudFront	Worker handles invalidation directly via `boto3` after S3 write
Finalization	`POST /admin/translate/complete/{job_id}` — LPO server endpoint (search rebuild, notification, cost, scale-down)
Protected Terms	57 brand/technical terms preserved via sentinel preprocessing
Validation	Multi-layer: tag counts, protected terms, protected zones, numeric preservation
Cost Protection	$600/day spend cap and a daily token cap (auto-reset), both checked before a customer is charged; up to 42 documents and 12 languages per request. Concurrent jobs are not capped: at 12 or more active jobs the LPO logs a warning and still queues the job.
Estimated Monthly Cost	~$2–5 (Bedrock invocations, usage-based)

Purpose: AWS Translate was evaluated and rejected for document translation — it corrupts code blocks, Mermaid diagrams, and brand terminology. This custom engine was purpose-built to understand the boundary between human language and machine language. It uses sentinel preprocessing to extract protected elements (translate="no" zones, code blocks, technical values) before translation, then restores them after. The result: 37 technical documents translated into 11 languages (407+ HTML files) with code blocks that still execute, diagrams that still render, and brand terms that remain untouched. Fire-and-forget — one API call handles translation, S3 deployment, CloudFront invalidation, search index rebuild, and email notification.

Translation Pipeline

Stage	Component	Action
Submit	`POST /admin/translate`	Validate, create task + jobs in Aurora, enqueue to SQS, scale workers to N
Translate	ECS Fargate workers (×N)	Long-poll SQS, sentinel preprocessing → Bedrock → validation → S3 write → CloudFront invalidation
Finalize	`POST /admin/translate/complete`	Search index rebuild, cost computation, notification email, scale workers to 1

Amazon SES (Simple Email Service) Active

Attribute	Value
Region	`us-east-2`
Domain	cpmp-site.org (verified)
`DMARC`	p=quarantine, pct=`100`
`BIMI`	Configured (logo at cpmp-site.org/images/bimi-logo.svg)
Senders	No-Reply, Support, Partners, Contact
Templates	CPMPNewsletterWelcome, LPONewsletterWelcome (12 languages each)
Multi-lingual	All email chrome (headings, labels, buttons) rendered in customer's preferred language

6c. Autonomous Operations (AutoOps)

A 5-layer intelligent operations system that monitors, defends, heals, and reports on the TBI infrastructure autonomously. Built on EventBridge, Step Functions, Lambda, and Amazon Bedrock. Designed to self-heal first, notify second — and escalate fast on unknowns.

Design Principle: If the system can fix it, fix it and tell Cory after. If the system doesn't know what to do, page Cory immediately. All autonomous actions are logged in Valkey for the daily digest. Estimated cost: ~$10–15/month total across all 5 layers.

Lambda Functions (7)

Function	Purpose	Runtime	Memory	Timeout	VPC	Status
`tbi-ops-notify`	Send SNS/SES notifications with severity context	provided.al2023 (Go)	`1770` MB	`60s`	No	Live
`tbi-ops-self-heal`	Restart ECS tasks, force-deploy services	provided.al2023 (Go)	`1770` MB	`60s`	No	Live
`tbi-ops-waf-action`	Apply/remove WAF IP blocks from honeypot queue	provided.al2023 (Go)	`1770` MB	`60s`	No	Live
`tbi-ops-honeypot-processor`	Drain honeypot queue, trigger WAF blocks	provided.al2023 (Go)	`1770` MB	`60s`	No	Live
`tbi-ops-bedrock-analyze`	AI-powered threat analysis via Bedrock (Qwen 3 235B)	provided.al2023 (Go)	`1770` MB	`60s`	No	Live
`tbi-rhema-support`	Rhema Support Assistant — auto-categorize tickets + AI draft responses (Qwen 3 235B)	provided.al2023 (Go)	`1770` MB	`180s`	No	Live
`tbi-ops-digest`	Generate daily/weekly operational digests + monthly newsletter via Bedrock (Qwen 3 235B). Reads the data layer live (`/public/infrastructure`, `/admin/feed-status`, CloudFront CloudWatch metrics, and the alarm inventory) when the collector cache is absent, so a session-gap morning still reports real Aurora/Valkey/feed/cluster/latency/traffic/alarm figures.	provided.al2023 (Go)	`1770` MB	`540s`	No	Live

Note: All AutoOps Lambdas are NOT in a VPC — they use public AWS service APIs (ECS, WAF, Bedrock, SNS, SES, CloudWatch). 1770 MB memory (multiple of 3) eliminates cold-start pain. Execution roles: tbi-autonomous-ops-role for the 4 AutoOps Lambdas that read the admin key, and tbi-autonomous-ops-noadmin-role for the 3 that read no secret at all (split 2026-10-11).

EventBridge Rules (7)

Rule	Schedule / Event	Target	Purpose	Status
`tbi-ops-alarm-trigger`	CloudWatch alarm state change	Step Function: `tbi-ops-health-check-heal`	Route alarm events to self-healing workflow	Enabled
`tbi-ops-honeypot-queue-processor`	`rate(5 minutes)`	Lambda: `tbi-ops-honeypot-processor`	Drain honeypot auto-block queue → apply WAF rules	Enabled
`tbi-ops-bedrock-analyze-schedule`	`rate(30 minutes)`	Lambda: `tbi-ops-bedrock-analyze`	Periodic AI threat analysis (skips when quiet)	Enabled
`tbi-ops-guardduty-high-finding`	GuardDuty finding (severity ≥ 7)	Lambda: `tbi-ops-bedrock-analyze`	Immediate AI analysis on HIGH/CRITICAL threats	Enabled
`tbi-ops-daily-digest`	`cron(0 11 * * ? *)` = 6 AM EST	Lambda: `tbi-ops-digest`	Daily 300-word operational summary	Enabled
`tbi-ops-weekly-digest`	`cron(0 12 ? * MON *)` = 7 AM EST Mon	Lambda: `tbi-ops-digest`	Weekly 500-word "Week in Review" with trends + subscriber newsletter	Enabled
`tbi-cpmp-monthly-newsletter`	`cron(0 15 ? * 1#1 *)` = 10 AM EST, 1st Sunday	Lambda: `tbi-ops-digest`	Monthly CPMP subscriber newsletter (auto-translated, 11 languages)	Enabled

Step Functions (1)

State Machine	Purpose	Trigger	Status
`tbi-ops-health-check-heal`	Orchestrates self-healing: wait → recheck → restart task → verify recovery → notify	EventBridge alarm events via `tbi-ops-alarm-trigger`	Live

SNS Topic

Topic	ARN	Purpose	Subscribers
`tbi-ops-notifications`	`arn:aws:sns:us-east-2:211998422884:tbi-ops-notifications`	Operational alerts with severity levels: [INFO], [WARNING], [CRITICAL], [SELF-HEALED]	Cory's email

WAF IP Set (AutoOps-managed)

Resource	ID	Attached To	Purpose
`tbi-autoops-blocked-ips`	`8d55de25-8ba5-4982-8c41-f4316c9bd50d`	`trinity-beast-api-waf` (priority 7, rule: `AutoOps-BlockedIPs`)	Dynamically managed block list — IPs added by honeypot processor and Bedrock recommendations

CloudWatch Anomaly Detection Retired

Retired — all four anomaly alarms and their detectors were removed (2026-07-30 through 2026-08-26). The four original anomaly-band alarms (TrinityBeast-Anomaly-RequestRate, -Latency, -ErrorRate, -CacheHitRate) no longer exist. They flapped continuously against healthy infrastructure and drove no-op self-heal runs. Two lessons drove the decision: an anomaly band cannot model a ratio at low volume (CacheHitRate collapses to 0 in any window with a miss and no hit), and it cannot model a bimodal metric (TBI latency mixes fast cached reads with slower admin/report endpoints). Where a metric needs an alarm going forward, the pattern is a static threshold (for example, a p99 latency alarm), not a trained anomaly model. Zero anomaly detectors remain in the account.

Amazon Bedrock

Attribute	Value
Model	`qwen.qwen3-235b-a22b-2507-v1:0` (Qwen 3 235B — loaded from the `agent_profiles` registry at runtime)
Region	`us-east-2`
Used By	`tbi-ops-bedrock-analyze`, `tbi-rhema-support`, `tbi-ops-digest`
Purpose	Threat analysis, support ticket categorization/drafting, operational digests + newsletter
Estimated Cost	~$2–5/month (cost-conscious — skips analysis when infrastructure is quiet)

IAM Role

Role	Used By	Policies
`tbi-autonomous-ops-role`	All 7 AutoOps Lambdas	ECS (update-service, stop-task), WAF (update-ip-set), CloudWatch (get-metrics, describe-alarms), Bedrock (invoke-model), SES (send-email), SNS (publish), SQS (receive/delete), Secrets Manager (get-secret), ElastiCache (connect via VPC)

Valkey Keys (AutoOps)

Key	Type	Purpose
`autoops:actions:log`	Sorted Set	All autonomous actions taken (scored by timestamp)
`autoops:last-digest`	String	Timestamp of last digest generation
`autoops:self-heal:count`	Counter	Self-heal actions this month
`autoops:threats:daily`	String (JSON)	Today's threat summary (rebuilt every 5 min)
`autoops:digest:daily`	String	Latest daily digest content
`autoops:digest:weekly`	String	Latest weekly digest content

7. Secrets & Security

Secrets Manager — `trinity-beast-secrets`

Single consolidated secret containing all application credentials. Used by all 3 ECS services, Lambda, and the Sync Job. 16 keys total.

#	Key	Description
1	`DB_HOST`	Aurora writer endpoint
2	`DB_PORT`	Aurora port (5432)
3	`DB_NAME`	Database name
4	`DB_USER`	Database username
5	`DB_PASSWORD`	Database password
6	`STRIPE_SECRET_KEY`	Stripe API secret key
7	`SES_SMTP_HOST`	SES SMTP endpoint
8	`SES_SMTP_PORT`	SES SMTP port (`587`)
9	`SES_SMTP_USER`	SES SMTP IAM username
10	`SES_SMTP_PASSWORD`	SES SMTP IAM password
11	`SES_REGION`	SES region (us-east-2)
12	`SES_FROM_NOREPLY`	No-Reply sender address
13	`SES_FROM_SUPPORT`	Support sender address
14	`SES_FROM_PARTNERS`	Partners sender address
15	`SES_FROM_CONTACT`	Contact sender address
16	`SES_DOMAIN`	Verified SES domain

⚠️ Security: Actual values are never stored in documentation or source code. All consumers read from Secrets Manager at runtime.

API Keys

Key	Purpose	Rate Limit	Status
`demo-public-2026-03-01-abc123`	Public demo (website + native demo binary)	3 QPS (demo) / 1,000 QPS (performance)	Active
`stress-test-unlimited-2026-04-20`	Stress testing	`100,000` QPS	Active

Web Application Firewalls (WAF)

WAF	Scope	Attached To	Rules
`CreatedByCloudFront-449feaa5`	CloudFront (Website)	Distribution `E110PRKEIYQVLL`	Anti-DDoS, IP Reputation, Common Rules, Known Bad Inputs
`trinity-beast-api-waf`	Regional (API)	ALB `Trinity-Beast-TCP-ALB`	IP Reputation, Common Rules, Known Bad Inputs, SQL Injection, Rate Limit Global (`2000/5min`), Rate Limit Admin (`6000/5min`), plus the AutoOps-managed `AutoOps-BlockedIPs` block rule

Threat Detection & Monitoring

Service	Resource	Purpose	Status
GuardDuty	Detector `18ceef6f8dddcf6082473cc7016ee458`	Automated threat detection — VPC flow logs, CloudTrail, DNS analysis	Active
Shield Standard	CloudFront + ALB	Automatic DDoS mitigation (Layer 3/4)	Active
CloudTrail	`trinity-beast-events-trail`	Multi-region API audit trail	Active
VPC Flow Logs	`fl-009c595743a159c57`, `fl-0549684b9986c6598`	Network traffic logging on both VPCs	Active

Security Alarms (CloudWatch)

Alarm	Trigger	Threshold
`TrinityBeast-WAF-HighBlockRate`	WAF blocks spike	Blocks spike
`TrinityBeast-API-5xx-Spike`	Server errors (target 5xx)	Server errors
`TrinityBeast-API-ELB-5xx-Spike`	ALB-generated 5xx	Load-balancer errors
`TrinityBeast-API-4xx-Spike`	Client errors / scanning	Client errors
`TBI-Security-IAM-Changes`	CloudTrail IAM change events	Any IAM change
`TBI-Security-EC2-RunInstances`	CloudTrail EC2 launches	Any RunInstances

Threat detection is handled by the tbi-ops-guardduty-high-finding EventBridge rule (GuardDuty severity ≥ 7 → tbi-ops-bedrock-analyze), not a CloudWatch alarm — the old TrinityBeast-GuardDuty-Finding alarm was retired because the AWS/GuardDuty namespace publishes no metric for it to watch.

Security Dashboard

Dashboard	Widgets	Region
`Trinity-Beast-Security-Dashboard`	CloudFront WAF, API WAF, Blocks by Rule, ALB Errors, ALB Latency, Security Alarms, ElastiCache Health	`us-east-2`

8. CloudWatch Dashboards & Alarm Notifications

Four CloudWatch dashboards provide real-time visibility into every layer of the infrastructure — application performance, security posture, cost intelligence, and a unified master view. 38 alarms monitor for threshold breaches and trigger notifications: 37 in us-east-2 (31 named monitoring alarms + 6 ECS auto-scaling TargetTracking-*) and 1 in us-east-1 (Trinity-Beast-CloudFront-5XX-High, since CloudFront metrics live only there). The live inventory is authoritative — derive it from aws cloudwatch describe-alarms rather than a frozen count.

Dashboards (4)

Dashboard	Purpose	Key Widgets	Region
`Trinity-Beast-Application-Dashboard`	Core application metrics — LPO, LRS, Lambda, and container health	CPU/Memory per service, request rates, latency p50/p99, cache hit ratios, Lambda invocations/errors/duration, container logs	`us-east-2`
`Trinity-Beast-Security-Dashboard`	Security & defense monitoring across all protection layers	CloudFront WAF allowed/blocked, API WAF allowed/blocked, blocks by rule (stacked), ALB error codes, ALB latency, security alarms panel, ElastiCache CPU/memory/hit rate	`us-east-2`
`Trinity-Beast-Master-Dashboard`	Unified overview combining application and infrastructure metrics	All ECS services, Aurora, ElastiCache, ALB/NLB, Lambda, CloudFront — single pane of glass	`us-east-2`
`Trinity-Beast-Cost-Dashboard`	Live cost intelligence — resource utilization metrics that drive spend, plus cost-context tables linking to Cost Explorer for exact dollar figures	Cost structure baseline + cost levers tables, ECS CPU/Memory utilization (4 services), Aurora ACU + utilization, ElastiCache CPU/memory, Lambda invocations + duration (8 functions), Aurora connections, NAT Gateway/EC2 data transfer	`us-east-2`

Alarms (31 named + 6 auto-scaling in us-east-2, 1 in us-east-1)

The named monitoring alarms below are current as of the last review; the live account is authoritative (aws cloudwatch describe-alarms). The 6 ECS TargetTracking-* alarms are auto-created by Application Auto Scaling and drive the scaling policies — they are not listed individually.

Alarm	Metric	Condition	Category
`Trinity-Beast-ECS-CPU-High`	ECS CPUUtilization (Main)	CPU > threshold	Compute
`Trinity-Beast-ECS-CPU-High-Mirror`	ECS CPUUtilization (Mirror)	CPU > threshold	Compute
`Trinity-Beast-ECS-CPU-High-LRS`	ECS CPUUtilization (LRS)	CPU > threshold	Compute
`Trinity-Beast-Main-Service-Count-Low`	ECS RunningTaskCount (Main)	Tasks < 1	Availability
`Trinity-Beast-Mirror-Service-Count-Low`	ECS RunningTaskCount (Mirror)	Tasks < 1	Availability
`Trinity-Beast-LRS-Service-Count-Low`	ECS RunningTaskCount (LRS)	Tasks < 1	Availability
`Trinity-Beast-Webhook-Service-Count-Low`	ECS RunningTaskCount (Webhook)	Tasks < 1	Availability
`Trinity-Beast-Translate-Worker-Count-Low`	ECS RunningTaskCount (Translate)	Tasks < 1	Availability
`Trinity-Beast-ALB-UnhealthyTargets`	ALB UnHealthyHostCount	Unhealthy > 0	Availability
`Trinity-Beast-NLB-UnhealthyTargets`	NLB UnHealthyHostCount	Unhealthy > 0	Availability
`Trinity-Beast-LRS-TargetGroup-Unhealthy`	Target group health (LRS 9090)	Unhealthy > 0	Availability
`Trinity-Beast-PrivateLink-8080-Unhealthy`	Target group health (8080)	Unhealthy > 0	Availability
`Trinity-Beast-PrivateLink-9090-Unhealthy`	Target group health (9090)	Unhealthy > 0	Availability
`Trinity-Beast-UDP-2680-Unhealthy`	UDP target group health (2680 LRS)	Unhealthy > 0	Availability
`Trinity-Beast-UDP-2681-Unhealthy`	UDP target group health (2681 Webhook Test)	Unhealthy > 0	Availability
`Trinity-Beast-Webhook-Test-8090-Unhealthy`	Target group health (8090 Webhook Test HTTPS)	Unhealthy > 0	Availability
`Trinity-Beast-Aurora-CPU-High`	RDS CPUUtilization	CPU > threshold	Database
`Trinity-Beast-Aurora-Connections-High`	RDS DatabaseConnections	Connections > threshold	Database
`Trinity-Beast-ElastiCache-ECPU-High`	ElastiCache ElastiCacheProcessingUnits	ECPU > threshold	Cache
`Trinity-Beast-ElastiCache-Storage-High`	ElastiCache BytesUsedForCache	Storage > threshold	Cache
`Trinity-Beast-ElastiCache-Throttled`	ElastiCache ThrottledCmds	Throttling > 0	Cache
`Trinity-Beast-S3-Size-Unusual-Growth`	S3 BucketSizeBytes	Unusual growth	Storage
`Trinity-Beast-Translation-DLQ-NotEmpty`	SQS translation DLQ depth	Messages > 0	Translation
`Trinity-Beast-ParamLoad-AuroraFallback-Recurring`	Log-metric: Aurora param-load fallback	≥ 3 in 1 hour	Config
`Trinity-Beast-Startup-MigrationFailure`	Log-metric: startup migration/seed failure	≥ 1 in 1 hour	Config
`TrinityBeast-WAF-HighBlockRate`	WAFV2 BlockedRequests	Blocks spike	Security
`TrinityBeast-API-5xx-Spike`	ALB HTTPCode_Target_5XX_Count	Server errors	Security
`TrinityBeast-API-ELB-5xx-Spike`	ALB HTTPCode_ELB_5XX_Count	ALB-generated 5xx	Security
`TrinityBeast-API-4xx-Spike`	ALB HTTPCode_Target_4XX_Count	Client errors / scanning	Security
`TBI-Security-IAM-Changes`	CloudTrail IAM change events	Any change	Security
`TBI-Security-EC2-RunInstances`	CloudTrail RunInstances events	Any launch	Security
`Trinity-Beast-CloudFront-5XX-High` (`us-east-1`)	CloudFront 5xxErrorRate	Error rate > threshold	Edge

Retired: TrinityBeast-GuardDuty-Finding (the AWS/GuardDuty namespace publishes no finding metric, so it could never fire — the working path is the tbi-ops-guardduty-high-finding EventBridge rule) and all four TrinityBeast-Anomaly-* alarms (see the Anomaly Detection note above). None of these exist in the account.

Access: All dashboards are accessible from the AWS Console at us-east-2.console.aws.amazon.com/cloudwatch/home?region=us-east-2#dashboards. The KCC provides direct access via bash scripts/kcc.sh daily (infrastructure report) and bash scripts/kcc.sh security (security report).

9. Price Feed Architecture

The Trinity Beast maintains persistent WebSocket connections to 6 exchanges. Every trade pushes a price update in real-time (sub-second latency). 360 assets are prewarmed across all feeds (expanded from 150 via successive rebalances) — split by real per-exchange liquidity rather than an even count: Coinbase 79, Kraken 72, OKX 69, Gate.io 64, Crypto.com 46, Bitstamp 30. Each feed has its own independent asset list, driven by the exchange_asset_map table and hot-reloadable without redeployment. Each of the 4 ECS containers maintains its own independent WebSocket connections for redundancy (24 total connections cluster-wide).

WebSocket Feeds — 6 Exchanges, 360 Prewarmed Assets

Exchange	Protocol	Endpoint	Pair Suffix	Source Tag
Coinbase	WebSocket	`wss://advanced-trade-ws.coinbase.com`	`USD`	`coinbase-ws`
Bitstamp	WebSocket	`wss://ws.bitstamp.net`	`USD`	`bitstamp-ws`
Kraken	WebSocket	`wss://ws.kraken.com/v2`	`USD`	`kraken-ws`
Gate.io	WebSocket	`wss://api.gateio.ws/ws/v4/`	`USDT`	`gateio-ws`
Crypto.com	WebSocket	`wss://stream.crypto.com/exchange/v1/market`	`USDT`	`cryptocom-ws`
OKX	WebSocket	`wss://ws.okx.com:8443/ws/v5/public`	`USDT`	`okx-ws`

Prewarmed Assets by Exchange (360 total)

Coverage is split by real per-exchange liquidity, not an even count, and it changes with each rebalance. The authoritative, always-current list is the exchange_asset_map table in Aurora (SELECT exchange_name, COUNT(*) FROM exchange_asset_map WHERE enabled=true AND prewarm=true GROUP BY exchange_name) — the counts below are the live distribution as of the last review, kept here for orientation rather than as a frozen roster.

Exchange	Prewarmed Assets	Source of Truth
Coinbase	79	`exchange_asset_map` (`exchange_name='coinbase'`)
Kraken	72	`exchange_asset_map` (`exchange_name='kraken'`)
OKX	69	`exchange_asset_map` (`exchange_name='okx'`)
Gate.io	64	`exchange_asset_map` (`exchange_name='gateio'`)
Crypto.com	46	`exchange_asset_map` (`exchange_name='cryptocom'`)
Bitstamp	30	`exchange_asset_map` (`exchange_name='bitstamp'`)
Total	360	363 total `exchange_asset_map` rows (360 enabled + prewarmed)

Feed Configuration Parameters

All six exchanges are now driven by the exchange_asset_map table — the single source of truth for which assets each feed subscribes to. The legacy *_prewarm_assets application parameters are kept in sync from that table (by sync-eam) for tooling that still reads them, but the table is authoritative. Per-exchange asset lists are not reproduced here because they change on every rebalance; query the table for the current roster.

Parameter	Value	Purpose
`exchange_asset_map`	363 rows (360 enabled + prewarmed)	Source of truth for all 6 feeds' subscription lists — columns `exchange_name`, `asset`, `exchange_symbol`, `enabled`, `prewarm`, `category`
`*_prewarm_assets`	Synced from `exchange_asset_map`	Legacy per-exchange lists (`coinbase_prewarm_assets`, `bitstamp_prewarm_assets`, etc.) — kept current by `sync-eam` for backward compatibility
`prewarm_assets_list`	Combined 360-asset list	Master combined prewarm list across all 6 exchanges (synced from the table)
`kraken_prewarm_interval_minutes`	3	Kraken REST batch poll interval (also used as general prewarm interval)
`kraken_prewarm_offset_seconds`	15	Stagger offset to avoid thundering herd across containers

Hot Path: (1) Local sync.Map → (2) ElastiCache → (3) REST fallback. WebSocket feeds write to Tier 1 on every trade. FlushToElastiCache() batch-writes all fresh local prices to Tier 2 every 30 seconds via Redis pipeline. 99.9% of requests served from Tier 1 (zero network hops). Each container maintains its own independent WebSocket connections for redundancy — 6 feeds × 4 containers = 24 persistent connections cluster-wide.

Asset Management: All six exchanges — Coinbase, Kraken, OKX, Gate.io, Crypto.com, and Bitstamp — are managed via the exchange_asset_map table in Aurora, synced to ElastiCache and hot-reloadable without redeployment. Assets beyond the 360 prewarmed are fetched on-demand from the best available exchange.

10. Performance Configuration

All settings are configurable via application_parameters in Aurora, synced to ElastiCache, and hot-reloadable via /admin/reload-params. The /admin/system-mode?mode=performance endpoint applies the full performance profile.

Parameter	Value	Purpose
`adaptive_max_concurrent`	6000	TCP governor — max simultaneous connections across cluster
`adaptive_success_threshold`	`0.50`	Governor throttle trigger threshold
`adaptive_throttle_delay_ms`	0	No artificial delay when throttling
`udp_max_concurrent_lpo`	3000	UDP LPO blocking governor per container
`udp_max_concurrent_lrs`	3000	UDP LRS blocking governor per container
`db_max_open_conns`	`150`	Aurora connection pool per container
`db_max_idle_conns`	75	Idle Aurora connections kept warm
`cache_pool_size`	`300`	ElastiCache connection pool per container
`cache_min_idle_conns`	60	Idle ElastiCache connections kept warm
`cache_dial_timeout_ms`	`500`	Fast-fail connection timeout
`cache_read_timeout_ms`	`500`	Fast-fail read timeout
`cache_write_timeout_ms`	`500`	Fast-fail write timeout
`sqs_batch_size`	10	Messages per SQS SendMessageBatch call (1-10)
`sqs_flush_ms`	`100`	SQS producer flush interval in milliseconds
`sqs_buffer_size`	50,000	SQS producer channel buffer capacity
`sqs_timeout_ms`	3,000	Per-batch SQS API call timeout in milliseconds
`http_idle_timeout_seconds`	`300`	Keep-alive connections held open
`http_read_timeout_seconds`	5	Fast-fail on slow reads
`http_write_timeout_seconds`	5	Fast-fail on slow writes
`cache_ttl_seconds`	9	Local cache TTL before checking ElastiCache
`log_level`	error	Minimal logging in performance mode

11. Stress Test Resources

Resource	Type	Purpose
`stress-test-ssm-role`	IAM Role	SSM access for stress test EC2 instances
`stress-test-ssm-profile`	IAM Instance Profile	Attached to stress test EC2 instances
`sg-0bec9c9fa46fb3be1`	Security Group	Stress test instance — reaches ECS containers directly
`lt-06c1d77f884da6b43`	Launch Template	trinity-beast-stress-run13 (us-east-2a, SSM profile)
`stress-test-unlimited-2026-04-20`	API Key	100K QPS rate limit for stress testing
`s3://trinity-beast-website-east2/tools/trinity-stress-linux`	S3 Object	Stress test binary (Go, Linux AMD64)

Test Client: m6in.4xlarge (16 vCPU, 64 GB, 50 Gbps networking), launched in us-east-2a (same AZ as containers). Supports TCP and UDP, round-robin distribution, per-container metrics, 13-level progressive load test.

12. Connection Map

Internet → The Trinity Beast (Inbound)

Path	Flow
TCP API	Client → Route 53 (`api.cpmp-site.org`) → ALB (TLS termination) → ECS containers (port 8080)
LRS Reports	Client → Route 53 (`lrs.cpmp-site.org`) → ALB (TLS termination) → ECS containers (port 9090)
UDP API	Client → Route 53 (`udp.cpmp-site.org`) → NLB (Layer 4) → ECS containers (port 2679/2680)
Website	Client → Route 53 (`cpmp-site.org`) → CloudFront → S3
Stripe Webhooks	Stripe → API Gateway → Lambda (`trinity-beast-receipt`)
Stripe Checkout	Client → Stripe (with `?locale=XX&client_reference_id=XX` from `cpmp_site.lang`) → Webhook → Lambda → Aurora (`preferred_lang`)

ECS Containers → Backend (Internal)

Connection	Purpose	Protocol
ECS → Aurora	Batched writes (`usage_logs`), reads (`api_keys`, config, `rate_limit_template`, `webhook_subscriptions`)	PostgreSQL (TCP 5432, `150` conns/container)
ECS → ElastiCache	Cache reads/writes, governor counters, config	Valkey (TCP 6379, TLS, `300` conns/container)
ECS → Coinbase WS	Real-time price feed (79 assets)	WebSocket (outbound, persistent)
ECS → Kraken WS	Real-time price feed (72 assets)	WebSocket (outbound, persistent)
ECS → OKX WS	Real-time price feed (69 assets)	WebSocket (outbound, persistent)
ECS → Gate.io WS	Real-time price feed (64 assets)	WebSocket (outbound, persistent)
ECS → Crypto.com WS	Real-time price feed (46 assets)	WebSocket (outbound, persistent)
ECS → Bitstamp WS	Real-time price feed (30 assets)	WebSocket (outbound, persistent)
ECS → CloudWatch	Logs and metrics	HTTPS (outbound)
Webhook → Associates	Outbound price push (UDP fire-and-forget + HTTPS signed `POST`)	UDP + HTTPS (outbound only)

Lambda → External (Outbound)

Connection	Purpose	Protocol
Lambda → Stripe API	Read checkout sessions (including locale), manage subscriptions, create portal sessions	`HTTPS`
Lambda → Aurora	Insert users, `api_keys`, transactions; read `rate_limit_template`; store `preferred_lang`	PostgreSQL (public endpoint)
Lambda → SES	Send receipt emails	HTTPS (SES API)
Lambda → api.cpmp-site.org	Cache invalidation (`/admin/invalidate-key`)	HTTPS (public ALB)
Lambda → lrs.cpmp-site.org	Cache invalidation (`/admin/invalidate-key`)	HTTPS (public ALB)

Designed to Persist

The Trinity Beast is built and operated by Cory Dean Kalani — one engineer, one vision, one binary. This is a deliberate architectural choice, not a limitation. The system is designed to run unassisted unless something occurs outside preset tolerances.

Every component is self-healing by design:

ECS Fargate — containers restart automatically on failure. Rolling deployments ensure zero-downtime updates.
WebSocket Feeds — auto-reconnect with exponential backoff. No manual intervention required when exchanges cycle connections.
Aurora Serverless — scales between 1.5–18 ACU automatically. Failover is managed by AWS.
ElastiCache — single-node Valkey with automatic recovery. Cluster stats republish every 3 seconds.
Nightly Sync — EventBridge cron fires at 1 AM EST daily. No human trigger required.
CloudWatch Alarms — SNS notifications alert on 5xx spikes, WAF block rates, and GuardDuty findings. Alert recipients are expandable to any number of contacts.
AutoOps (5 Layers) — AI-powered self-healing, threat analysis, support automation, and daily digests. 7 Lambdas + 7 EventBridge rules run autonomously — fix problems first, notify after.
Financial Pipeline — Stripe processes subscriptions and donations, distributes funds on schedule, and CPMP reimburses infrastructure costs. Revenue flows to the mission without manual intervention.
Documentation — Comprehensive documentation covers every component, every deployment procedure, every architectural decision. Any engineer with Go experience and AWS access can operate this system from documentation alone.

The Trinity Beast does not require a babysitter. It runs itself, heals itself, and serves its purpose without manual intervention. Human attention is reserved for evolution — not survival. This is a miracle machine with a mission.

Table of Contents

1. Infrastructure Summary

2. Compute Layer — ECS Fargate

Lambda

SQS — Usage Log Queue

SQS — Email Queue

3. Data Layer

4. Network Layer

DNS (Route 53)

VPC

Security Groups

5. Content Delivery & Storage

6. Scheduled Tasks & Automation

6b. AI & Translation Services

Translation Flow

Translation Pipeline

6c. Autonomous Operations (AutoOps)

Lambda Functions (7)

EventBridge Rules (7)

Step Functions (1)

SNS Topic

WAF IP Set (AutoOps-managed)

CloudWatch Anomaly Detection Retired

Amazon Bedrock

IAM Role

Valkey Keys (AutoOps)

7. Secrets & Security

Secrets Manager — trinity-beast-secrets

API Keys

Web Application Firewalls (WAF)

Threat Detection & Monitoring

Security Alarms (CloudWatch)

Security Dashboard

8. CloudWatch Dashboards & Alarm Notifications

Dashboards (4)

Alarms (31 named + 6 auto-scaling in us-east-2, 1 in us-east-1)

9. Price Feed Architecture

WebSocket Feeds — 6 Exchanges, 360 Prewarmed Assets

Prewarmed Assets by Exchange (360 total)

Feed Configuration Parameters

10. Performance Configuration

11. Stress Test Resources

12. Connection Map

Designed to Persist

Secrets Manager — `trinity-beast-secrets`