Dayton, NJ

Shahzaib
Khan

DevOps / Platform Engineer

I turn manual, ticket-driven operations into systems that run themselves.

Drawn by
Shahzaib Khan
Location
Dayton, NJ
Current
RxSense / DevOps / Platform Engineer
Certification
AWS Solutions Architect, in progress

About

I build and modernize AWS infrastructure for a pharmacy benefit platform that runs 24/7 with no acceptable downtime. Most of the work comes down to one thing: taking manual, fragile, ticket-driven operations and turning them into automated, self-service systems the team can rely on.

I came into this from an unusual direction. I have a Mechanical Engineering degree from NJIT, and I moved through sales and applications engineering before going deep on infrastructure. Teaching myself cloud and platform engineering, mostly on the job and mostly by taking on work above my title, is the thing I am most proud of.

I work across AWS, Terraform, Kubernetes and CI/CD, I share an on-call rotation for a production system that cannot go down, and I am working toward my AWS Solutions Architect certification.

The constraint

Built for a platform with no acceptable downtime.

Selected work

01

Multi-account AWS migration

Environments
~15
Provisioning
Days to ~1 hr
Cutover
~30 sec
Delivery
4 mo, solo
env env env env env env env env production non-production terraform modules BeforeAfter
Fig. 01 One hand-built account, rebuilt as two accounts on shared modules

ProblemAbout fifteen environments lived in a single overloaded AWS account that had been built by hand over several years. Cross-account dependencies were tangled and undocumented, and there was no infrastructure as code underneath any of it.

I split the estate into separate production and non-production accounts, then rebuilt it in Terraform as versioned, application-based modules, so a full environment now stands up from a small set of variables.

I migrated one environment at a time on a controlled schedule, with regression and smoke testing at each step, to keep the blast radius small.

Cutovers ran at near zero downtime, around thirty seconds each. I stood up parallel infrastructure and moved DNS under Terraform control during off hours.

ResultProvisioning a new environment went from days of manual setup to about an hour, and the whole estate became reproducible, standardized and version controlled. Delivered solo over roughly four months.

02

Self-healing automated patching pipeline

Cadence
Monthly, hands-off
Gate
Health check + approval
Rollout
Canary, all envs
schedule ci build bake image launch tmpl test env tickets approval canary health gate all envs Phase 1, automaticPhase 2, approved
Fig. 02 Two phases, separated by a human approval, gated on a real health check

ProblemServers were patched by hand on a monthly cadence, partly by an outside team, with after-hours manual swaps in production and real room for human error. Nothing healed itself.

I built the pipeline end to end. A scheduled trigger starts CI, which bakes a new machine image, versions the launch template, and rolls it out through a health-gated instance refresh.

A lifecycle hook and a per-application health check confirm each new instance is actually serving traffic before the old one retires, which is what makes the refresh safe rather than merely automatic.

The first phase runs on its own to a test environment and opens tracking tickets. The second phase waits for a human approval, then rolls canary style to the remaining environments including production, with notifications at every step.

ResultRemoved a standing external dependency and hours of after-hours on-call work every cycle. Monthly patching became a hands-off, reliable and auditable process across every environment.

03

Cloud cost optimization

Production savings
Tens of thousands / mo
Downtime
Zero
Mechanism
One Terraform change
Cloud cost optimization A decision tree for matching capacity to demand. Variable traffic routes to request-based autoscaling, predictable traffic routes to scheduled scaling, and stable workloads stay static. Alongside it, instance sizing is matched to workload shape rather than left uniform. traffic shape variable predictable stable requestscaling scheduledscaling static,on purpose right-size to the workload
Fig. 03 Capacity matched to demand, with static left static on purpose

ProblemProduction and lower environments ran large instance types at static capacity regardless of real demand. Nothing was matched to the workload it was actually carrying.

I read the utilization data and matched resources to real workloads, right-sizing instances and choosing compute-optimized or general-purpose families to fit what each workload was doing.

Where traffic varied I added request-based autoscaling. Where it was predictable I added scheduled scaling. Where a workload was genuinely stable I left it static on purpose, which is a decision rather than an oversight.

All of it went out with zero downtime through the same health-gated instance refresh, driven by a single Terraform change.

ResultTens of thousands of dollars per month in production savings, recognized by leadership, plus meaningful additional annual savings across non-production environments.

04

Self-service tenant onboarding tool

Tickets
Several / wk to self-serve
Access model
Scoped, read and create
Status
Live, daily use
Self-service tenant onboarding tool A user reaches a guarded tool, which holds the scoped cloud role and service account. Only the tool crosses the boundary into the sensitive file-transfer and storage systems. The user never does. onboardingteam guardedtool filetransfer storage holds scoped roleand service accounttrustboundary
Fig. 04 The tool holds the privileged access, so the team never crosses the boundary

ProblemA non-technical team needed client tenants onboarded, but the underlying file-transfer and storage systems were too sensitive to hand them directly. Every onboarding became an engineering ticket, several times a week.

I built an internal tool that exposes only safe, scoped operations behind a guided interface. The tool holds the privileged access itself, a scoped cloud role and a scoped service account, so the team never touches the sensitive systems.

The team can see what already exists and create new tenants from minimal input. They have no direct access and no edit access to anything underneath.

ResultTurned a recurring ticket stream into self-service, freed engineering time, and gave the other team visibility they had never had. Live and in daily use.

05

Kubernetes fleet-visibility platform

Scope
Prod + non-prod
Access
Read-only
Status
Live, in use
clusters workloads logs manifests collector datastore fleet views anomalies cost search grounded assistant
Fig. 05 Several sources, one collector, one datastore, one read-only view

ProblemKubernetes management was scattered across tools, production and non-production lived in different places, and there was no single view of the fleet or its cost. There was also no lightweight anomaly detection independent of the main monitoring stack.

I co-built a read-only platform that pulls several sources into one fleet view covering clusters, nodes, workloads, logs and manifests.

On top of that we added independent anomaly detection with trend analysis over stored time-series data, per-cluster and per-namespace cost visibility, and fast workload search.

An assistant answers questions grounded in the data the platform has already collected, rather than making live calls out to the clusters.

ResultOne place for engineers and leadership to see the whole fleet, its health and its cost. Live and in use.

06

.NET Framework 4.8 to .NET 10 migration

in progress
Method
Weighted canary
Cost control
One image, both runtimes
Outage
None user-facing
.net 4.8 .net 10 .net 4.8 .net 10 .net 4.8 .net 10 .net 10 stage 1stage 2stage 3stage 4
Fig. 06 Weighted traffic shifting from the 4.8 fleet to the .NET 10 fleet

ProblemCore applications needed to move from .NET Framework 4.8 to .NET 10 without disrupting a platform that runs 24/7.

I am co-leading a canary migration that runs both runtimes in parallel and shifts traffic gradually using weighted load balancing, with a feature flag for the scheduler service, so the blast radius stays small throughout.

To control cost we bake both runtimes into a single machine image rather than duplicating full infrastructure, and we coordinate an environment-by-environment cutover schedule around the existing build pipelines.

ResultA gradual, low-risk runtime upgrade of core services with no user-facing outage. In progress.

Skills

Cloud
  • AWS
  • EC2
  • S3
  • RDS
  • Lambda
  • Route 53
  • CloudWatch
  • CloudTrail
  • Secrets Manager
  • ElastiCache / Redis
  • EventBridge
  • IAM
  • Auto Scaling
  • ALB / NLB
  • Multi-account architecture
Infrastructure as code
  • Terraform
  • Terraform modules
  • Remote state
  • Drift detection
  • Packer
  • CloudFormation
CI/CD and release
  • GitHub Actions
  • Octopus Deploy
  • Bamboo
  • Bitbucket Pipelines
Containers and orchestration
  • Kubernetes
  • Amazon EKS
  • Rancher
  • kubectl
  • Helm
  • Docker
  • ECR
Observability and on-call
  • New Relic
  • NRQL
  • PagerDuty
  • CloudWatch
  • Slack integrations
Scripting
  • Python
  • PowerShell
  • Bash
Practices
  • Canary deployments
  • Blue/green deployments
  • Autoscaling strategy
  • Cost optimization
  • Incident response
  • Change management
  • Secrets management
Certification
  • AWS Solutions Architect, in progress

Experience

  1. Apr 2025 to present

    DevOps / Platform Engineer

    RxSense , Princeton, NJ / current

    Build and modernize AWS infrastructure for a pharmacy benefit platform that runs 24/7. The work above is from this role.

  2. Jul 2022 to Apr 2025

    Applications / Support Engineer

    Crestron Electronics , Rockleigh, NJ

    Post-sales technical support down to source code and configuration. Promoted into Premier Support for top-tier clients.

  3. Jun 2021 to Jun 2022

    Sales Engineer

    Johnson Controls , Rockaway, NJ

    Assessed requirements and negotiated proposals for fire and life-safety systems.

  4. 2021

    B.S. Mechanical Engineering

    New Jersey Institute of Technology

Contact

Open to DevOps, Platform, and SRE roles

Email
shahzaib.khan7434@gmail.com
Phone
Email instead
LinkedIn
Profile
Resume
Download PDF