The Trinity Beast Infrastructure — CloudFormation Recovery Guide

1. You describe what you want in a YAML file (the "template")
2. You run one command — aws cloudformation create-stack
3. AWS builds everything — in the right order, with the right connections
4. AWS tracks it all as a "stack" — you can update, monitor, or delete everything as a unit

The foundation. Think of the VPC as the building itself — it defines the walls and rooms. Subnets are the rooms. The Internet Gateway is the front door. Security groups are the locks on each room's door.

Resource	Details	Purpose
VPC	10.0.0.0/16 (65,536 IPs)	The private network — your building
Public Subnets	3 subnets across 3 AZs	Rooms with windows — internet-facing (load balancers live here)
Private Subnets	3 subnets across 3 AZs	Interior rooms — no direct internet access (databases, servers live here)
Internet Gateway	1 IGW attached to VPC	The front door to the internet
Route Tables	4 route tables	Hallway signs — tell traffic where to go
Security Groups	7 security groups	Door locks — control who can talk to what
VPC Endpoints	10 endpoints	Private back doors to AWS services (no internet needed)
Flow Logs	VPC Flow Logs → CloudWatch	Security cameras — record all network traffic

IAM roles are like employee badges — they define what each service is allowed to do. A server can read from the database but can't delete the network. Each role follows the principle of least privilege: only the permissions needed, nothing more.

Role	Purpose
ECS Task Execution Role	Lets ECS pull Docker images from ECR and write logs to CloudWatch
ECS Task Role	Lets the running containers access Secrets Manager, S3, SES, and other AWS services
EventBridge Role	Lets the scheduler (EventBridge) launch ECS tasks for the nightly sync job
Flow Logs Role	Lets VPC Flow Logs write to CloudWatch Logs
Lambda Execution Role	Lets the receipt Lambda function write logs and access needed services

Where your data lives. Aurora is the main database (think: filing cabinets). ElastiCache is the speed cache (think: sticky notes on your desk for things you need instantly). ECR stores your Docker images. S3 stores your website files.

Resource	Details	Purpose
Aurora Serverless v2	PostgreSQL 17.7, 1–21 ACU, Optimized I/O	Main database — writer + reader instances
ElastiCache for Valkey	Valkey 7.3, db.r7g.large, 13 GB, TLS	In-memory cache — sub-millisecond reads
ECR Repositories	5 repositories	Docker image storage (like a private Docker Hub)
S3 Bucket	cpmp-ministry-site-east2	Website files, CloudFormation templates, backups
Secrets Manager	trinity-beast-secrets	Encrypted storage for DB passwords, Stripe keys, API keys

The workers. ECS Fargate runs your containers without you managing servers. Think of it as hiring workers and only paying for the hours they work — no building maintenance. Lambda runs small, one-off tasks (like processing a receipt after a purchase).

Resource	Details	Purpose
ECS Cluster	trinity-beast-fargate-cluster	The factory floor — organizes all services
Main Service	trinity-beast-main-service — 8 vCPU / 32 GB	LPO + LRS (SERVER_TYPE: APP_REPORT_SERVER)
Mirror Service	trinity-beast-mirror-service — 8 vCPU / 32 GB	LPO + LRS (SERVER_TYPE: APP_REPORT_SERVER)
LRS Service	trinity-beast-lrs-service — 8 vCPU / 32 GB	LPO + LRS (SERVER_TYPE: APP_REPORT_SERVER)
Webhook Service	trinity-beast-webhook-service — 8 vCPU / 32 GB	Webhook Push delivery engine (SERVER_TYPE: WEBHOOK_SERVER)
Sync Job Task Def	trinity-beast-sync-job	Nightly database sync task definition
Lambda Function	trinity-beast-receipt — Go (provided.al2023)	Post-checkout receipt processing
SQS Queue	trinity-beast-queued-usage-logs — Standard	Decoupled usage log write pipeline
Lambda Function	trinity-beast-queued-writer — Go (provided.al2023)	SQS consumer — batch-inserts usage logs into Aurora

Load balancers are traffic cops. They stand at the front door and direct incoming requests to the right server. The ALB handles web traffic (HTTP/HTTPS). The NLB handles UDP traffic (real-time price feeds).

Resource	Listeners	Purpose
ALB (Trinity-Beast-TCP-ALB)	Port 80, 443, 8080, 9090	Web traffic — API, LRS reports, HTTPS redirect
NLB (Trinity-Beast-UDP-NLB)	UDP 2679, 2680	Real-time UDP price feeds
Target Groups	4 target groups	Route traffic to the right ECS service

DNS is the phone book of the internet. When someone types cpmp-site.org, DNS tells their browser which server to talk to. Route 53 manages all of this.

Record	Points To	Purpose
cpmp-site.org	CloudFront	Main website
www.cpmp-site.org	CloudFront	WWW alias for website
api.cpmp-site.org	ALB	REST API endpoint
lrs.cpmp-site.org	ALB	LRS report server
udp.cpmp-site.org	NLB	UDP price feed endpoint
MX record	SES inbound	Email receiving
SPF record	TXT record	Email authentication — "yes, we're allowed to send email"
DMARC record	TXT record	Email policy — tells receivers how to handle our email
SES verification	TXT/CNAME records	Proves we own the domain for sending email

CloudFront is like having copies of your website in cities around the world. Instead of everyone connecting to Ohio, visitors get served from the nearest location. Faster for them, less load on your servers.

Setting	Value
Origin	S3 bucket (cpmp-ministry-site-east2)
HTTP → HTTPS	Automatic redirect
TLS Version	TLS 1.2 minimum
Certificate	ACM certificate in us-east-1 (CloudFront requirement)

Monitoring is your early warning system. CloudWatch watches metrics (CPU usage, error rates, database health) and SNS sends you a text or email when something goes wrong. You find out about problems before your users do.

Category	Alarms	What They Watch
ECS CPU	CPU alarms per service	Container CPU usage — alerts if consistently high
ECS Service Count	Running task count	Alerts if a service has zero running tasks (it's down)
Aurora	CPU, connections, storage	Database health — CPU spikes, connection exhaustion
ElastiCache	CPU, memory, connections	Cache health — memory pressure, connection limits
ALB/NLB	5xx errors, unhealthy targets	Load balancer health — are requests failing?

EventBridge is your cron job in the cloud. It runs tasks on a schedule without you lifting a finger.

Rule	Schedule	What It Does
trinity-beast-nightly-sync	cron(0 6 * * ? *) = 1:00 AM EST	Launches the sync job ECS task to synchronize database data nightly

graph TB
    Internet["Internet"]

    subgraph DNS_CDN["DNS & CDN"]
        Route53["Route 53
cpmp-site.org"]
        CloudFront["CloudFront
Static Website"]
        S3["S3 Bucket
trinity-beast-website-east2"]
    end

    subgraph LoadBalancers["Load Balancers"]
        ALB["ALB
Trinity-Beast-TCP-ALB
TCP: 80, 443 → 8080, 9090"]
        NLB["NLB
Trinity-Beast-UDP-NLB
UDP: 2679, 2680"]
    end

    subgraph ECS["ECS Fargate Cluster — 4 Services"]
        Main["BeastMain · AZ 2a
APP_REPORT_SERVER
8 vCPU / 32 GB"]
        Mirror["BeastMirror · AZ 2b
APP_REPORT_SERVER
8 vCPU / 32 GB"]
        LRS["BeastLRS · AZ 2c
APP_REPORT_SERVER
8 vCPU / 32 GB"]
        Webhook["BeastWebhook
WEBHOOK_SERVER
8 vCPU / 32 GB"]
    endB"]
    end

    subgraph Data["Data Layer"]
        Aurora["Aurora PostgreSQL
Serverless v2
2–18 ACU"]
        MemDB["ElastiCache
Valkey 7.2
cache.r7g.2xlarge · 52 GB"]
        Secrets["Secrets Manager
trinity-beast-secrets"]
    end

    Lambda["Lambda
trinity-beast-receipt
Go / provided.al2023"]
    EventBridge["EventBridge
Nightly Sync
1 AM EST"]
    SyncJob["Sync Job
0.5 vCPU / 1 GB"]
    SNS["SNS
Critical Alerts
Email + SMS"]
    CW["CloudWatch
4 Dashboards
14 Alarms"]

    Internet --> Route53
    Route53 -->|"cpmp-site.org"| CloudFront
    Route53 -->|"api / lrs"| ALB
    Route53 -->|"udp"| NLB
    CloudFront --> S3
    Internet -->|"Stripe Webhook"| Lambda

    ALB -->|"TCP 8080"| Main
    ALB -->|"TCP 8080"| Mirror
    ALB -->|"TCP 9090"| LRS
    NLB -->|"UDP 2679"| Main
    NLB -->|"UDP 2679"| Mirror
    NLB -->|"UDP 2680"| LRS

    Main --> Aurora
    Main --> MemDB
    Mirror --> Aurora
    Mirror --> MemDB
    LRS --> Aurora
    LRS --> MemDB
    Webhook --> Aurora
    Webhook --> MemDB

    Main -.->|"!GetAtt Endpoint"| Aurora
    Main -.->|"!GetAtt Endpoint"| MemDB
    Main -.->|"Reads"| Secrets

    Lambda --> Aurora
    Lambda --> MemDB
    Lambda -.->|"Reads"| Secrets

    EventBridge -->|"cron 0 6 * * ?"| SyncJob
    SyncJob --> Aurora
    SyncJob --> MemDB

    CW -.->|"ALARM"| SNS

    %% Internet → DNS — white
    linkStyle 0 stroke:#e2e8f0,stroke-width:2px
    %% DNS → CDN — pink (website path)
    linkStyle 1 stroke:#f472b6,stroke-width:2px
    %% DNS → ALB — blue (TCP)
    linkStyle 2 stroke:#60a5fa,stroke-width:2px
    %% DNS → NLB — orange (UDP)
    linkStyle 3 stroke:#FF9900,stroke-width:2px
    %% CloudFront → S3 — pink
    linkStyle 4 stroke:#f472b6,stroke-width:2px
    %% Internet → Lambda — violet (Stripe)
    linkStyle 5 stroke:#a78bfa,stroke-width:2px
    %% ALB → ECS — blue (TCP)
    linkStyle 6 stroke:#60a5fa,stroke-width:2px
    linkStyle 7 stroke:#60a5fa,stroke-width:2px
    linkStyle 8 stroke:#60a5fa,stroke-width:2px
    %% NLB → ECS — orange (UDP)
    linkStyle 9 stroke:#FF9900,stroke-width:2px
    linkStyle 10 stroke:#FF9900,stroke-width:2px
    linkStyle 11 stroke:#FF9900,stroke-width:2px
    %% ECS → Aurora — red (database)
    linkStyle 12 stroke:#f87171,stroke-width:2px
    linkStyle 14 stroke:#f87171,stroke-width:2px
    linkStyle 16 stroke:#f87171,stroke-width:2px
    linkStyle 18 stroke:#f87171,stroke-width:2px
    %% ECS → ElastiCache — green (cache)
    linkStyle 13 stroke:#10b981,stroke-width:2px
    linkStyle 15 stroke:#10b981,stroke-width:2px
    linkStyle 17 stroke:#10b981,stroke-width:2px
    linkStyle 19 stroke:#10b981,stroke-width:2px
    %% !GetAtt / !Ref wiring — cyan (dashed)
    linkStyle 20 stroke:#22d3ee,stroke-width:1.5px
    linkStyle 21 stroke:#22d3ee,stroke-width:1.5px
    %% Secrets reads — rose
    linkStyle 22 stroke:#fca5a5,stroke-width:1.5px
    %% Lambda → Aurora — red
    linkStyle 23 stroke:#f87171,stroke-width:2px
    %% Lambda → ElastiCache — green
    linkStyle 24 stroke:#10b981,stroke-width:2px
    %% Lambda → Secrets — rose
    linkStyle 25 stroke:#fca5a5,stroke-width:1.5px
    %% EventBridge → SyncJob — yellow
    linkStyle 26 stroke:#facc15,stroke-width:2px
    %% SyncJob → Aurora — red
    linkStyle 27 stroke:#f87171,stroke-width:2px
    %% SyncJob → ElastiCache — green
    linkStyle 28 stroke:#10b981,stroke-width:2px
    %% CloudWatch → SNS — rose (alerts)
    linkStyle 29 stroke:#fca5a5,stroke-width:1.5px

    style Internet fill:#FF9900,color:#0f172a,stroke:#FF9900
    style ALB fill:#1e293b,stroke:#60a5fa,color:#e2e8f0
    style NLB fill:#1e293b,stroke:#FF9900,color:#e2e8f0
    style Main fill:#064e3b,stroke:#10b981,color:#e2e8f0
    style Mirror fill:#064e3b,stroke:#10b981,color:#e2e8f0
    style LRS fill:#064e3b,stroke:#10b981,color:#e2e8f0
    style Webhook fill:#064e3b,stroke:#10b981,color:#e2e8f0
    style Aurora fill:#1e293b,stroke:#f87171,color:#e2e8f0
    style MemDB fill:#1e293b,stroke:#10b981,color:#e2e8f0
    style Lambda fill:#1e293b,stroke:#a78bfa,color:#e2e8f0
    style CloudFront fill:#1e293b,stroke:#f472b6,color:#e2e8f0
    style S3 fill:#1e293b,stroke:#f472b6,color:#e2e8f0
    style Route53 fill:#1e293b,stroke:#e2e8f0,color:#e2e8f0
    style Secrets fill:#7f1d1d,stroke:#fca5a5,color:#e2e8f0
    style SNS fill:#7f1d1d,stroke:#fca5a5,color:#e2e8f0
    style CW fill:#1e293b,stroke:#60a5fa,color:#e2e8f0
    style SyncJob fill:#1e293b,stroke:#facc15,color:#e2e8f0
    style EventBridge fill:#1e293b,stroke:#facc15,color:#e2e8f0
        

The Aurora cluster endpoint is automatically passed to all 4 ECS task definitions as the DB_HOST environment variable. When CloudFormation creates the Aurora cluster, it gets an endpoint like trinity-beast-aurora.cluster-xxxxx.us-east-2.rds.amazonaws.com. That endpoint is injected into every container so they know where the database is — no hardcoding needed.

The ElastiCache cluster endpoint is passed to all 4 ECS task definitions as the CACHE_URL environment variable. Same idea — CloudFormation creates the cache, gets the endpoint, and passes it to the containers automatically.

Security groups reference each other to create a chain of trust:

• The ALB security group allows traffic from the internet (ports 80, 443)
• The ECS tasks security group allows traffic only from the ALB security group — not from the internet directly
• The Aurora security group allows traffic only from the ECS tasks security group — only your servers can reach the database
• The ElastiCache security group allows traffic only from the ECS tasks security group — same protection for the cache

This is defense in depth. Even if someone bypasses the load balancer, they can't reach the database directly because the security group only trusts traffic from the ECS containers.

Route 53 records use !GetAtt to point at the load balancers:

• api.cpmp-site.org → ALB's DNS name (automatically resolved)
• udp.cpmp-site.org → NLB's DNS name
• cpmp-site.org → CloudFront distribution domain

If the load balancer's address changes (e.g., after a rebuild), the DNS records update automatically because they reference the resource, not a hardcoded IP.

The Secrets Manager secret ARN is passed to ECS task definitions. At runtime, ECS pulls the secret values and injects them as environment variables. Your application code never sees the raw secret — it just reads environment variables like DB_PASSWORD and STRIPE_SECRET_KEY.

1. AWS CLI installed and configured — run aws sts get-caller-identity to verify you're authenticated to account 211998422884
2. ACM certificates — you need two SSL certificates already created and validated:
   • One in us-east-2 (for the ALB)
   • One in us-east-1 (for CloudFront — this is an AWS requirement, CloudFront only uses us-east-1 certs)
3. Docker images in ECR — the template references ECR repos, but you need to push images to them after the repos are created (or have them ready to push)
4. The secret values — your database password and the JSON secrets string (Stripe keys, etc.)

aws cloudformation create-stack \
  --stack-name trinity-beast-stack \
  --template-body file://trinity-beast-stack.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-2 \
  --parameters \
    ParameterKey=DBPassword,ParameterValue='YOUR_DB_PASSWORD_HERE' \
    ParameterKey=SecretValue,ParameterValue='{"DB_PASSWORD":"...","STRIPE_SECRET_KEY":"...","STRIPE_WEBHOOK_SECRET":"..."}' \
    ParameterKey=DBUsername,ParameterValue=postgres \
    ParameterKey=DBName,ParameterValue=CPMP_Backend_Aurora \
    ParameterKey=DomainName,ParameterValue=cpmp-site.org \
    ParameterKey=AlertEmail,ParameterValue='[email]' \
    ParameterKey=AlertSMS,ParameterValue='[phone]' \
    ParameterKey=LPOImageTag,ParameterValue=latest \
    ParameterKey=SyncImageTag,ParameterValue=latest

CloudFormation reads the template, figures out the dependency order, and starts creating resources. Here's the rough timeline:

Time	What's Happening
0–2 min	VPC, subnets, internet gateway, route tables created
2–5 min	Security groups, VPC endpoints, IAM roles created
5–15 min	Aurora cluster spinning up (this is the slowest part)
5–15 min	ElastiCache cluster spinning up (runs in parallel with Aurora)
10–20 min	ECR repos, S3 bucket, Secrets Manager created
15–25 min	ECS cluster, task definitions, ALB, NLB created
20–30 min	ECS services start (4 services — they'll fail health checks until images are pushed)
25–35 min	Route 53 records, CloudFront distribution, CloudWatch alarms
30–45 min	Stack complete — all 126 resources created

The stack creates the infrastructure, but some things need to be done manually after:

1. 1Push Docker images to ECR — your ECS services are running but have no code yet

   # Authenticate Docker to ECR
   aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 211998422884.dkr.ecr.us-east-2.amazonaws.com
   
   # Tag and push the LPO server image
   docker tag trinity-beast-lpo-server:latest 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-lpo-server:latest
   docker push 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-lpo-server:latest
   
   # Tag and push the sync job image
   docker tag trinity-beast-sync-job:latest 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-sync-job:latest
   docker push 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-sync-job:latest

2. 2Deploy Lambda code — upload the Go binary to the Lambda function

   aws lambda update-function-code \
     --function-name trinity-beast-receipt \
     --zip-file fileb://bootstrap.zip \
     --region us-east-2

3. 3Upload website to S3

   aws s3 sync ./website/ s3://cpmp-ministry-site-east2/ --delete

4. 4Invalidate CloudFront cache

   aws cloudfront create-invalidation \
     --distribution-id E110PRKEIYQVLL \
     --paths "/*"

5. 5Verify DNS resolution

   dig api.cpmp-site.org
   dig udp.cpmp-site.org
   dig cpmp-site.org
   curl -I https://api.cpmp-site.org/health

# Check overall stack status
aws cloudformation describe-stacks --stack-name trinity-beast-stack --region us-east-2

# Watch events in real-time (useful during creation)
aws cloudformation describe-stack-events \
  --stack-name trinity-beast-stack \
  --region us-east-2 \
  --query 'StackEvents[0:10].[Timestamp,ResourceType,LogicalResourceId,ResourceStatus]' \
  --output table

# List all resources in the stack
aws cloudformation list-stack-resources \
  --stack-name trinity-beast-stack \
  --region us-east-2

aws cloudformation update-stack \
  --stack-name trinity-beast-stack \
  --template-body file://trinity-beast-stack.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-2 \
  --parameters \
    ParameterKey=DBPassword,UsePreviousValue=true \
    ParameterKey=SecretValue,UsePreviousValue=true

CloudFormation compares your new template against the current state and categorizes each change:

Change Type	What Happens	Example
No Interruption	Resource is updated in place — no downtime	Changing a CloudWatch alarm threshold
Some Interruption	Resource is briefly interrupted during update	Changing an ECS task definition (rolling deploy)
Replacement	Old resource is deleted and a new one is created	Changing VPC CIDR block, Aurora engine version

aws cloudformation create-change-set \
  --stack-name trinity-beast-stack \
  --template-body file://trinity-beast-stack.yaml \
  --change-set-name my-changes \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-2

# Review what will change
aws cloudformation describe-change-set \
  --stack-name trinity-beast-stack \
  --change-set-name my-changes \
  --region us-east-2

1 Run create-stack with the template

This is the big one. One command creates all 126 resources:

aws cloudformation create-stack \
  --stack-name trinity-beast-stack \
  --template-body file://trinity-beast-stack.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-2 \
  --parameters \
    ParameterKey=DBPassword,ParameterValue='YOUR_DB_PASSWORD' \
    ParameterKey=SecretValue,ParameterValue='YOUR_SECRETS_JSON'

Then wait. Monitor progress:

aws cloudformation describe-stacks --stack-name trinity-beast-stack --region us-east-2 \
  --query 'Stacks[0].StackStatus' --output text

2 Wait for stack to complete

Watch for CREATE_COMPLETE. This takes 30–45 minutes. Aurora and ElastiCache are the slowest. Go get coffee.

3 Push Docker images to the new ECR repos

The ECR repos are empty — they're just containers waiting for images. Build and push:

# Authenticate
aws ecr get-login-password --region us-east-2 | \
  docker login --username AWS --password-stdin \
  211998422884.dkr.ecr.us-east-2.amazonaws.com

# Build and push LPO server
docker build -t trinity-beast-lpo-server:latest .
docker tag trinity-beast-lpo-server:latest \
  211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-lpo-server:latest
docker push 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-lpo-server:latest

# Build and push sync job
docker build -t trinity-beast-sync-job:latest -f Dockerfile.sync .
docker tag trinity-beast-sync-job:latest \
  211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-sync-job:latest
docker push 211998422884.dkr.ecr.us-east-2.amazonaws.com/trinity-beast-sync-job:latest

ECS will automatically pick up the new images and start the services.

4 Deploy Lambda code

# Build the Go binary for Lambda
GOOS=linux GOARCH=arm64 go build -o bootstrap cmd/receipt/main.go
zip bootstrap.zip bootstrap

# Deploy to Lambda
aws lambda update-function-code \
  --function-name trinity-beast-receipt \
  --zip-file fileb://bootstrap.zip \
  --region us-east-2

5 Upload website files to S3

aws s3 sync ./cpmp-redesign/ s3://cpmp-ministry-site-east2/ --delete

6 Invalidate CloudFront

aws cloudfront create-invalidation \
  --distribution-id E110PRKEIYQVLL \
  --paths "/*"

7 Update Route 53 nameservers at domain registrar

If the hosted zone was recreated, it gets new nameservers. You must update them at your domain registrar (wherever you bought cpmp-site.org).

# Get the new nameservers
aws route53 get-hosted-zone --id YOUR_HOSTED_ZONE_ID \
  --query 'DelegationSet.NameServers' --output text

Copy those 4 nameserver values and update them at your registrar. DNS propagation can take up to 48 hours, but usually completes within 1–2 hours.

8 Verify all services are healthy

# Check ECS services
aws ecs describe-services \
  --cluster trinity-beast-fargate-cluster \
  --services trinity-beast-main-service trinity-beast-mirror-service trinity-beast-lrs-service trinity-beast-webhook-service \
  --region us-east-2 \
  --query 'services[].{name:serviceName,running:runningCount,desired:desiredCount,status:status}'

# Check API health
curl -s https://api.cpmp-site.org/health | jq .

# Check ALB target health
aws elbv2 describe-target-health \
  --target-group-arn YOUR_TARGET_GROUP_ARN \
  --region us-east-2

# Check Aurora
aws rds describe-db-clusters \
  --db-cluster-identifier trinity-beast-aurora \
  --region us-east-2 \
  --query 'DBClusters[0].Status'

# Check ElastiCache
aws elasticache describe-cache-clusters \
  --cluster-name trinity-beast-cache \
  --region us-east-2 \
  --query 'Clusters[0].Status'

trinity-beast-lpo-server/deployments/cloudformation/trinity-beast-stack.yaml

This is the canonical version. All edits should be made here and then synced to S3.

s3://cpmp-ministry-site-east2/cloudformation/trinity-beast-stack.yaml

A copy in S3 for redundancy. You can deploy directly from S3 using --template-url instead of --template-body:

aws cloudformation create-stack \
  --stack-name trinity-beast-stack \
  --template-url https://cpmp-ministry-site-east2.s3.us-east-2.amazonaws.com/cloudformation/trinity-beast-stack.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-2 \
  --parameters ...

trinity-beast-lpo-server/deployments/cloudformation/inventory/

This directory contains 72 JSON files — one for every resource's current configuration as captured from the live AWS environment. These serve as a reference if you need to verify that the CloudFormation template matches what's actually deployed. They're snapshots, not live data.