Cloud infrastructure · DevOps · Operations

I architect Multi-Cloud infrastructure and the checks that make deployments trustworthy.

I'm George Koufie, a Solutions Architect at EpixDevo, where I own AWS and Azure migration contracts for clients moving off unreliable IT. My work combines Terraform, cloud networking, delivery pipelines, and the troubleshooting habits developed while supporting enterprise users — documented below as projects, not just claims.

Portrait of George Koufie
Solutions Architect at EpixDevo, owning AWS & Azure migrations7 featured builds with code or project evidenceEnterprise IT background in support and operationsAWS & Azure certifications
Current role

Where this work happens now

Solutions Architect — EpixDevo

Contract · July 2026 – Present · Savannah, GA (remote)
  • Own AWS and Azure migration contracts for EpixDevo's clients — industrial and commercial businesses moving off unreliable or outgrown IT.
  • Architect cloud infrastructure sized to each client's actual operation, matching EpixDevo's approach to managed IT: not oversold to the business it serves.
  • Apply the same measured, evidence-first engineering practice shown in the projects below to real client migrations.
Available for

Contract engagements, outside EpixDevo's client base

My EpixDevo role covers migration contracts for their own clients. Outside that, I take on a limited number of engagements in these areas — each backed by a project you can inspect below, not just a claim.

Cloud migration & architecture

Designing and executing AWS/Azure migrations, landing zones, and hybrid network connectivity.

Disaster recovery design & drills

Setting RTO/RPO targets before a build exists, then running real failover drills and publishing the measured result — including when a target is missed.

Infrastructure as Code

Terraform modules and guardrails built to be destroyed and rebuilt, not just applied once and left alone.

Hybrid & multi-cloud networking

Site-to-Site VPN, Transit Gateway, and the routing and security-group debugging that actually gets traffic flowing.

Selected work

Projects with inspectable evidence

Each project connects an engineering claim to its repository or documented validation. These are portfolio builds.

01 / Site reliability engineering

SaaS SRE lab: SLO burn-rate alerting and two measured DR drills

Claim. Built a SaaS-style service on AWS with explicit SLOs and burn-rate alerting, then injected five real production failures and measured how long each took to detect. Followed that with two separate disaster-recovery drills: a local Kubernetes drill that deleted a StatefulSet and its volume (RTO 92s, RPO 216s), and a real AWS drill that used RDS point-in-time restore to recover 166,721 deleted rows in under 16 minutes.

Engineering focus. Burn-rate alerting tuned against real SLOs rather than raw thresholds, and the write-up stays honest about what the numbers actually show: the RPO target was met "by timing, not design," an aggregate SLO missed a real regression that only a per-route check caught, and two tooling gaps were found and documented rather than hidden — backup jobs that failed silently and produced 0-byte files, and a backup size that shrank 17% with nothing alerting on it.

AWS RDSKubernetesSLO / Burn-rateGrafanaTerraform
Measured results
  • Local K8s drill (StatefulSet + volume deleted): RTO 92s, RPO 216s.
  • AWS RDS point-in-time restore: 166,721 deleted rows recovered in under 16 minutes.

Five injected failures were each timed from injection to detection, and the gaps the drills exposed in backup verification are documented alongside the successful recovery — not left out.

02 / Patch orchestration

PatchPilot: patching that schedules itself around real batch workloads

Claim. Built a patch-orchestration tool that plans maintenance windows from each customer's actual batch-processing history, not just a schedule definition — then patches a mixed RHEL and Windows fleet through Salt while deliberately keeping Java and Tomcat pinned to their certified versions. It reproduces and automatically remediates two real Java-on-RHEL failure modes: SELinux silently flipping back to Enforcing and breaking app connectivity, and a Tomcat upgrade breaking a legacy screen.

Engineering focus. A planner that learns each workflow's real p95 finish time per weekday (schedules say when a job starts, not when it actually finishes), gated runs that abort cleanly before touching anything if a batch job is still running or a check already fails, and two real incidents from the AWS lab along the way: a STIG scan silently froze a database node by exhausting memory with no swap configured, and a subtler one — oscap's own output uses a separator that Python's line-splitting treats as a line break, so 4,295 lines of real scan results silently parsed into zero rules, which had already produced one false "scan ok" before it was caught. Both diagnosed through EC2 status checks, system logs, CloudWatch, and Salt's own job cache — not guessed at.

SaltRHEL / STIGOpenSCAPServiceNowTerraformAWS SSM
Try it without any cloud resources
  • A --simulate mode runs the full plan/patch/validate/report cycle on a laptop in-memory — no AWS needed to see it work.

After those fixes, the real AWS lab completed a full patch cycle end to end: database, app, and Windows tiers patched and rebooted, an injected SELinux break caught and fixed while staying Enforcing, re-validated, with real STIG scan results improving (258 to 257 failing rules).

03 / Systems hardening

Centralized OS patching for a mixed Linux/Windows fleet, with zero inbound access

Claim. Built a mixed Amazon Linux, Ubuntu, and Windows Server EC2 fleet patched entirely through AWS Systems Manager — no server ever reachable over SSH or RDP. Measured before (164 missing patches, 1 of 4 nodes compliant) and after (0 missing, 0 failed, 3 of 4 compliant — the 4th left non-compliant on purpose as a control, to show what happens without follow-up).

Engineering focus. A custom Windows baseline and patch group routing only security/critical updates, a weekly maintenance window with concurrency and error-threshold limits, and three real issues found and fixed: a package-manager lock conflict from a duplicate patch run, a Windows security update missing from Patch Manager's own catalog (fixed via a direct Run Command, not the baseline), and a maintenance window silently pointed at the wrong SSM document, caught by checking the API instead of trusting the console.

AWS Systems ManagerPatch ManagerEC2IAMCloudFormation
Measured result
  • 164 missing patches → 0, across Linux and Windows, with 0 failed installs.

Runtime was about 6.5 hours, for an estimated $1.40. Teardown was verified directly: no instances, volumes, Elastic IPs, IAM roles, or managed nodes left behind.

04 / Virtualization

VMware ESXi lab: real licensing limits, and monitoring proven by an injected failure

Claim. Built a nested VMware ESXi 8.0U3e environment from scratch, then found — through four separate operations that all returned the identical API error — that the free license blocks VM cloning, OVF deployment, and even reconfiguring an existing VM through the API; Terraform's vsphere provider crashed outright for a related reason. Automated configuration and monitoring with Ansible instead, and didn't stop at "deployed": stopped a monitored service on purpose and measured how long detection actually took.

Engineering focus. Diagnosing a Hyper-V/VT-x conflict that blocked nested virtualization before the VM would even power on, an Ansible playbook that hardens SSH and deploys a Python health-check tool plus a Prometheus/Grafana stack with its datasource and dashboard provisioned as code, and a firewall rule that had been silently blocking all of it until found and fixed.

VMware ESXigovcAnsiblePrometheusGrafana
Measured result
  • Monitoring detection drill: target 6 minutes (committed before the test), measured 4 minutes 23 seconds. Met.
05 / Disaster recovery

Azure disaster recovery drill: VM and SQL failover

Claim. Ran two real Azure failover drills between West US and Central US and measured them: an Azure Site Recovery VM failover and an Azure SQL failover group under a live write load. RTO and RPO targets were committed to the repository before each run, and the results are published as measured, including the one target I missed.

Engineering focus. Terraform-built infrastructure, Site Recovery replication and failover, SQL failover groups, timing recovery from the recovered VM's own log, and a cost guardrail set before anything billable existed. Both labs were torn down and checked against Azure afterward.

Azure Site RecoveryAzure SQLTerraformRTO / RPO
Measured results
  • VM failover: RTO target 15 min, measured 2 min 34 s (met). RPO target 5 min, measured 5 min 4 s (missed by 4 seconds).
  • SQL failover group: RTO target 60 s, measured 12.9 s (met). Forced failover lost about 2.3 s of writes; planned failover lost none.
06 / Disaster recovery

EKS GitOps service with a measured database recovery drill

Claim. Deployed a service to EKS on Fargate with Argo CD, backed by Aurora, then ran a real recovery drill: the database was killed mid-traffic and restored while recovery time was measured against a target set beforehand. Target RTO was 2 minutes; measured recovery was 39 seconds.

Engineering focus. Terraform and Terragrunt for the VPC and cluster, GitOps delivery with Argo CD, Aurora, and diagnosing real failures along the way, including CoreDNS pods stuck Pending on Fargate and an AWS VPC quota limit that moved the deployment to another region. Everything was torn down and verified at zero cost afterward.

EKS FargateArgo CDAuroraTerraform
Inspect the source

The repository records what was not built as well: Datadog was deliberately not deployed because no account existed, and the write-up says so.

07 / AWS networking

Hybrid Cloud Network Architecture

Claim. Built a Terraform-based network design using Transit Gateway and site-to-site VPN components, then tested rebuildability through destroy and reapply.

Engineering focus. Routing, IPsec connectivity, reusable infrastructure code, and fixing a GitHub Actions OIDC trust-policy error during deployment.

AWS Transit GatewayVPNTerraformOIDC
Inspect the source
08 / Networking

AWS Site-to-Site VPN across two regions

Claim. Built a real AWS Site-to-Site VPN — IPsec, a Virtual Private Gateway, a Customer Gateway, static routing — connecting two simulated company networks in two different AWS regions, with no router or ISP cooperation needed since both sides are AWS. Verified with an actual ping and SSH hostname check routed through the gateway and across the tunnel, not just a status light.

Engineering focus. Terraform building both VPCs and the VPN connection end to end, Libreswan configured with the real tunnel address and pre-shared key straight from Terraform’s own outputs, and two real bugs found with tcpdump after the obvious fixes did not work: IP forwarding disabled by default, and a security group that allowed the reply direction but not the forward direction — both produced the identical symptom until isolated.

AWS Site-to-Site VPNIPsecTerraformLibreswan
Measured result
  • Ping through the tunnel: 4 of 4 packets, 0% loss, ~47ms RTT. SSH hostname check confirmed a genuinely different server answered, in the other region.
09 / Disaster recovery

Automated DR with proven RTO/RPO: scheduled chaos drills, built twice

Claim. Built multi-region AWS disaster recovery two ways — active-passive (Aurora Global Database, DynamoDB global tables, Route 53 failover) and active-active (Aurora DSQL, synchronous cross-region writes) — then proved both with AWS Fault Injection Service chaos drills that break the primary region on a schedule and publish the measured result, including the runs that failed.

Engineering focus. An automated failover runbook and an analyzer that grades each drill from client-observed data, not self-reported status. The first real drill session found two genuine bugs no local test caught: a Step Functions expression using the wrong SDK field-name casing left the runbook stuck polling for 8 minutes after Aurora had already failed over, and a DynamoDB replication link that broke before the injected fault reached every execution environment, losing 33 acknowledged writes against a 5-second RPO target — a real limit of asynchronous multi-region replication, not a bug. The active-active rebuild removed the failover step entirely: recovery is Route 53 latency routing, with 0 of 1,265 writes lost.

AWS FISAurora Global DBAurora DSQLRoute 53Step FunctionsTerraform
Measured results
  • Active-passive: best drill RTO 129.1s, but graded FAIL — DynamoDB RPO 33s against a 5s target. 0 of 2 drills passed, both root causes documented and fixed.
  • Active-active: PASS. Longest client outage 54.0s (target 120s), automatic recovery in 27.9s with no runbook, 0 of 1,265 writes lost.

Every number is computed from the committed evidence — per-second probe samples and the full Step Functions execution history sit next to each drill's result.json, so any figure can be recomputed.

Other work: Serverless Link Shortener API ↗.

Writing

How the pieces connect

The projects above are the evidence. This is the reflection on building them in sequence — why disaster recovery on AWS led to Azure, then to VMware, then to a real hybrid network link.

LinkedIn · October 2026

From Disaster Recovery to Hybrid Cloud: My Hands-On Journey in Cloud Infrastructure Engineering

Four projects, each one leading into the next — AWS disaster recovery, Azure Site Recovery and SQL failover, a VMware ESXi lab, and an AWS Site-to-Site VPN across two regions. The piece is less about the resume line each project adds and more about what connected them: the same RTO/RPO discipline, carried from cloud to cloud to on-prem.

LinkedIn · August 2026

Building the AWS Backend for a Volunteer-Matching Platform: Serverless, Terraform, and a Bug That Taught Me Something About Lambda Layers

A serverless backend for a volunteer-matching platform — Lambda, API Gateway, DynamoDB, atomic transactions to stop two volunteers claiming the same slot at once. The real story is the bug: a shared Python module Lambda refused to import, traced back to the layer's ZIP not following the required python/ folder structure. Terraform said the deploy succeeded; the endpoints said otherwise.

Medium

How I Reduced Deployment Errors with a GitHub Actions CI/CD Pipeline on AWS EC2

Manual deployment is where human error actually lives — the wrong version tagged, a validation step skipped under time pressure. The pipeline: GitHub Actions runs tests and a Trivy security scan, builds the Docker image, deploys it to an EC2 server Terraform provisioned, then checks a real health endpoint before calling it done. Same release steps, every time, with nothing left to remember.

GitHub ActionsTerraformDockerTrivy
Capabilities

Tools I use, connected to work I can show

Hands-on focus

  • AWS infrastructure: VPC networking, IAM, EC2, serverless services, and logging.
  • Infrastructure as code: Terraform modules and automated validation.
  • Delivery: GitHub Actions, Docker, Kubernetes, and deployment checks.
  • Operations: incident triage, identity management, documentation, and troubleshooting.

Selected credentials

  • AWS Certified Solutions Architect – Associate
  • Microsoft Certified: Azure Administrator Associate
  • LPI Linux Essentials
  • CompTIA Security+ and Network+
  • B.S. Cloud Computing · Western Governors University

A credential verifies study and testing; project links show implementation. The résumé has the full certification list and employment details.

Verified badges

Issued by AWS, Microsoft, LPI, and CompTIA (via Credly).

AWS Certified Solutions Architect – Associate certificate issued to George Koufie, July 12, 2025, expires July 12, 2028. Verify at aws.amazon.com/verification.Microsoft Certified: Azure Administrator Associate certificate issued to George Koufie, earned July 4, 2025, expires July 4, 2027.Linux Professional Institute Linux Essentials certificate issued to George Koufie, February 19, 2024. Verify at lpi.org/v/LPI000601604/rtjhnckexp.
Get in touch

Have a migration, DR plan, or Terraform project that needs architecting?

I'm currently a Solutions Architect at EpixDevo, owning AWS and Azure migration contracts for their clients. Outside that client base, I take on a limited number of contract engagements in cloud architecture, disaster recovery, and Infrastructure as Code — reach out if that's what you need.