Architecture proven by code.
A repository-backed account of the AWS topology and Terraform decisions. CIDRs, ports, hostnames, instance sizes, region and account identifiers are documentation examples rather than production values.
KOLVerse AWS Architecture
The topology matches production; CIDRs, hostnames, ports, instance sizes, region and account identifiers are replaced with documentation examples. The illustrated VPC is 10.20.0.0/16 with separate Website, Admin and API target groups behind one TLS-enabled ALB.
Why the system is shaped this way
Stable ingress, explicit routing
Route 53 aliases converge on one HTTPS ALB. Host rules send the website, API, admin, and Grafana to dedicated instance target groups, while health checks remove unhealthy targets from routing.
Application ports behind the ALB
Website, API, and admin security groups use ALB security-group references for application ingress. SSH is separately CIDR-scoped. This is stronger than open application ports, but the public-subnet placement and public IPs remain real attack-surface debt.
Separate compute and state
Each application surface runs on its own encrypted EC2 volume. S3 holds persistent assets and the API receives access through an IAM instance profile, so AWS credentials do not need to be embedded in containers.
Reuse with acknowledged coupling
Staging creates independent instances and routing rules but looks up the production VPC, subnet, security groups, ALB, and listener. This lowers cost while coupling environment availability and change coordination.
Reviewable changes, repeatable reconciliation.
Terraform turns infrastructure changes into a Git diff and a plan before AWS is changed. In this repository, production also records previously existing infrastructure as managed resources, while staging composes on top of shared foundations through data lookups.
terraform/
├── environments/
│ ├── prod/ # imported production VPC, EC2, ALB + DNS, S3, IAM
│ └── staging/ # shared-foundation lookups + staging compute/routing
└── modules/
├── networking/ # reusable VPC/public/private/NAT design (not invoked by current envs)
├── security/
├── alb/
├── compute/ec2/
└── s3/terraform init
terraform fmt -check
terraform validate
terraform plan
terraform apply # applied manually after a reviewed planIngress is chained by intent.
The example ALB uses ports 80/443. Example application ports 3000 and 8080 are allowed by source security group instead of global CIDRs, while the example administrative port 22 remains CIDR-scoped.
Internet (80/443)
↓
ALB security group
├── SG reference → Website :3000
├── SG reference → API :8080
└── SG reference → Admin :3000
Example admin CIDR 203.0.113.0/24 → SSH :22 (website, API, admin)What the current design buys—and costs.
Dedicated EC2 hosts
Benefit: simple workload separation and direct operational control.
Cost: manual host capacity, patching, single-instance failure domains, and public-addressed compute.
Shared ALB and network
Benefit: lower staging cost and centralized TLS/host routing.
Cost: listener priorities, security groups, and foundational changes are coupled across environments.
Imported production resources
Benefit: existing AWS infrastructure becomes visible and reviewable in Terraform.
Cost: lifecycle ignore rules can mask console drift and weaken convergence.
Next changes, ordered by the problem they solve.
- Move workloads to private subnets and use SSM-only management.
Removes public instance addresses and SSH ingress while preserving controlled operations.
- Add redundant compute across Availability Zones.
The ALB is multi-AZ, but each application is currently a single EC2 target in one zone.
- Separate staging state and network boundaries.
Reduces blast radius when isolation matters more than the cost of shared foundations.
- Add a remote state backend and a plan/approval/apply pipeline.
State is local and applies are manual today; a reviewed pipeline with locked remote state would make every infrastructure change traceable.