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

Multi-account AWS migration

Environments: ~15
Provisioning: Days to ~1 hr
Cutover: ~30 sec
Delivery: 4 mo, solo

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.

Self-healing automated patching pipeline

Cadence: Monthly, hands-off
Gate: Health check + approval
Rollout: Canary, all envs

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.

Cloud cost optimization

Production savings: Tens of thousands / mo
Downtime: Zero
Mechanism: One Terraform change

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.

Self-service tenant onboarding tool

Tickets: Several / wk to self-serve
Access model: Scoped, read and create
Status: Live, daily use

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.

Kubernetes fleet-visibility platform

Scope: Prod + non-prod
Access: Read-only
Status: Live, in use

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.

.NET Framework 4.8 to .NET 10 migration

in progress

Method: Weighted canary
Cost control: One image, both runtimes
Outage: None user-facing

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.

Labs

Self-directed work, built to understand technologies properly rather than just use them. The first three connect: an access model written in SQL, the same model managed as Terraform, and the pipeline that deploys it.

1 / 4

snowflake-admin-sql
Snowflake access management in SQL

Snowflake platform administration worked through in SQL. A two-layer role model where access roles hold privileges on objects and functional roles map to job functions, so a team's scope changes with one grant rather than forty. Service user setup with key-pair authentication, and audit queries covering who holds what, who lacks MFA, and where the credits went. The layer underneath the Terraform project, and what you fall back on when an auditor asks a question no config file answers.
- SQL
- Snowflake
View repository
2 / 4

snowflake-platform-tf
The same access model, as Terraform

Terraform configuration managing Snowflake databases, schemas, warehouses and role-based access, using the access-role and functional-role pattern with future grants. Remote state in S3 with versioning and encryption, key-pair JWT authentication for the service user, and a three-stage GoCD pipeline that validates, plans, then applies behind a manual approval.
- Terraform
- Snowflake
- GoCD
- AWS S3
View repository
3 / 4

gocd-local-lab
The pipeline that deploys it

A GoCD server and agent stack on Docker Compose for authoring and testing pipelines without a hosted CI environment. A custom agent image with Terraform built in, resource tagging to route jobs to the right agent, a named volume so configuration and history survive container recreation, and manual agent approval.
- GoCD
- Docker Compose
- Terraform
- Ubuntu
View repository
4 / 4

image-hardening-lab
Container image hardening, measured

The same Flask app built twice, once naively and once hardened, then both scanned and compared. Multistage build, slim base image, non-root user with a pinned UID, and a production WSGI server in place of the development one. The hardened image dropped from 1.63 GB to 213 MB with a substantially lower CVE count, then deployed to ECS Fargate with a read-only root filesystem.
- Docker
- Trivy
- Hadolint
- Syft
- Amazon ECR
- ECS Fargate
View repository

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
Self-directed: Snowflake
GoCD
SQL
ECS Fargate
Trivy
Hadolint
Syft
Docker Compose
Certification: AWS Solutions Architect, in progress

Experience

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.
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.
Jun 2021 to Jun 2022

Sales Engineer

Johnson Controls , Rockaway, NJ

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

B.S. Mechanical Engineering

New Jersey Institute of Technology

Contact

Open to DevOps, Platform, and SRE roles

Email: [email protected]
Phone: Email instead
GitHub: Shaz-Khan431
LinkedIn: Profile
Resume: Download PDF

Shahzaib Khan

About

Selected work

Labs

Snowflake access management in SQL

The same access model, as Terraform

The pipeline that deploys it

Container image hardening, measured

Skills

Experience

DevOps / Platform Engineer

Applications / Support Engineer

Sales Engineer

B.S. Mechanical Engineering

Open to DevOps, Platform, and SRE roles

Shahzaib
Khan