Algonquin College · Emerging Technologies · Jan – Apr 2026

Hybrid MSP Infrastructure & AWS Kubernetes Service

A 17-VM, two-site managed-service environment for two client tenants, delivered on Proxmox with OPNsense firewalls, Windows Server 2022 AD and Samba AD — then extended with a public HTTPS web service running on a kubeadm Kubernetes cluster provisioned in AWS with Terraform.

Proxmox VE OPNsense Windows Server 2022 Samba AD iSCSI Veeam Backup OpenVPN AWS EC2 Route 53 Terraform kubeadm Flannel Docker Caddy Let's Encrypt

Read Technical Report (PDF) ↗ ← Back to portfolio

01By the numbers

17Virtual machines on the public-cloud site

2Client tenants (Lumora + ClearRoots)

8VLAN segments across MSP, tenant LAN, DMZ, and SAN

2Sites linked by OpenVPN with Veeam backup copy

9AWS resources provisioned with Terraform

2Node kubeadm cluster on EC2 (1 CP + 1 worker)

02The brief

Emerging Technologies is a capstone course that hands the team a blank-slate MSP contract: design, build, and operate shared infrastructure for two fictional client companies, across two physical sites, to a set of availability and security requirements. The environment is then extended with a public-facing cloud service — the "emerging technology" in our case being Kubernetes on AWS, provisioned with Terraform.

Deliverables were a working lab, a 122-page technical report, a client-facing SLA document, and a live defence.

03On-prem MSP environment

Two Proxmox VE hosts, one per site, hosting everything from domain controllers to client workstations. OPNsense handled routing between sites over an OpenVPN site-to-site tunnel, with strict VLAN segmentation so a compromise on one tenant couldn't cross to the other.

Two Proxmox VE clusters, one per site, carrying all client and management VMs.
OPNsense firewalls terminating a site-to-site OpenVPN tunnel with per-tenant routing tables.
VLAN segmentation per tenant and per function (servers, workstations, management, storage).
Windows Server 2022 for one tenant's AD DS forest; Samba AD for the other to demonstrate interop.
iSCSI SAN providing shared storage for backups and archival.
Veeam Backup & Replication jobs targeting the SAN with retention policies per tenant SLA.
Documented runbooks for restore drills, user onboarding, and password reset.

04AWS Kubernetes extension

The "emerging technology" portion was a live, public HTTPS service running on a self-managed Kubernetes cluster in AWS, with every AWS resource declared in Terraform so the whole thing could be torn down and rebuilt from scratch during the defence demo.

resource "aws_instance" "control_plane" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.k8s.id]
  key_name               = aws_key_pair.capstone.key_name
  user_data              = file("scripts/bootstrap-cp.sh")

  tags = {
    Name    = "capstone-k8s-cp"
    Role    = "control-plane"
    Project = "capstone"
  }
}

VPC with public subnet and security groups scoped to 6443, 80, 443, and SSH from a single admin IP.
Two EC2 instances (1 control plane, 1 worker) bootstrapped with kubeadm.
Flannel CNI for pod networking.
Dockerized nginx pod exposing the site.
Caddy running on the control-plane host as an ingress proxy, auto-issuing Let's Encrypt TLS.
Route 53 A record pointing capstone.<domain> at the control-plane Elastic IP.
Terraform remote state in S3 with DynamoDB locking so the team could apply concurrently.

05My scope

End-to-end ownership of the public-cloud site (Site 2) — the MSP edge, both tenants' full infrastructure stacks, the dual-bastion operations layer, the Veeam backup target, and the AWS-hosted public service extension were all designed, built, and operated solo. The on-prem site (Site 1) was delivered collaboratively.

MSP edge, segmentation & cross-site

OPNsense gateway (rp-msp-gateway) with 8 VLAN segments across MSP, per-tenant LAN, DMZ, and isolated SAN bridges. Firewall aliases and policies enforcing tenant separation, NAT publication for the bastions only, and a site-to-site OpenVPN tunnel carrying Veeam backup copy and controlled cross-site traffic back to Site 1.

Lumora (Windows tenant)

Windows Server 2022 AD DS forest c1.local with two domain controllers (DNS, DHCP, Group Policy), a Windows file server presenting SMB shares over an isolated iSCSI SAN, an IIS web server in the DMZ, and Windows + Ubuntu domain-joined endpoints.

ClearRoots (Linux tenant)

Samba AD on Ubuntu (c2.local) with two DHCP-failover-paired identity nodes (DNS, DHCP, SMB), a Linux file server with iSCSI-backed shares and replicated directory structure, an nginx web server in the DMZ, and a domain-joined Linux client.

Bastions, backup & operations

Dual-bastion entry model — Jump64 (Windows, RDP-published on a high port) for AD/Veeam work and MSPUbuntuJump (Linux, SSH-published on a high port) for Linux tenant and OPNsense inspection. S2Veeam as the Site 2 backup repository and offsite copy target with explicit firewall paths. Documented runbooks, dependency maps, and fast-triage tables.

AWS public-service extension

Terraform-provisioned AWS footprint (9 resources: IAM role + instance profile, security group, two EC2 instances, Elastic IP, Route 53 A record, S3 remote state) running a 2-node kubeadm cluster. Nginx Deployment exposed via NodePort, fronted by Caddy on the worker for automatic Let's Encrypt TLS — published at clearroots.omerdengiz.com.

06What I'd change next time

Move TLS into cert-manager + an nginx ingress controller — more realistic for a production environment.
Replace the raw kubeadm cluster with a managed option (EKS, GKE) for a production deployment.
Add Prometheus + Grafana to both the MSP and the cluster — the on-prem side had Zabbix, but unified observability would have been cleaner.
Terraform modules instead of a single root — the team hit merge pain near deadlines where module boundaries would have helped.