sahil@koundal
available for projects
Open to DevOps & SRE opportunities

Sahil
Koundal

DevOps Engineer Cloud Infrastructure SRE Hybrid Networking

I build and run production infrastructure on AWS — and I make it cheaper, faster and more predictable. Migrations that cut real money off the bill, pipelines that turn week-long releases into minutes, and private connectivity that replaces flaky internet paths.

Work with me See the engagements résumé ↗
Experience 3+ years Certified AWS SAA · CCP
Annual spend removed $10K+ migration & right-sizing
Deployment time −70% Jenkins + Terraform
Uptime held 99.9% zero-downtime rollouts
Image size −50% multi-stage builds
Core stack
AWS Terraform Docker Kubernetes Ansible Jenkins Argo CD Prometheus Grafana Linux

01 / about

Infrastructure that costs less and breaks less.

I'm a DevOps / Cloud / SRE engineer with 3+ years running production systems on AWS and Azure. Most of my work sits at the intersection of three things: automation (Terraform, Ansible, Jenkins, Argo CD), cost (migration, right-sizing, VPC endpoints, alias records, reserved capacity) and connectivity (Site-to-Site VPN, Direct Connect, MPLS). Security and compliance — Trivy, SonarQube, PCI-DSS and RBI requirements — are part of the pipeline, not a phase at the end.

01

Automate

Everything repeatable becomes code — provisioning, builds, releases, recovery.

02

Measure

One dashboard, real SLOs, alerts that mean something at 3 a.m.

03

Optimize

Cost is an architecture problem. I fix the path, not just the invoice.

04

Harden

Private paths, scanned images, least privilege, audit-ready evidence.

02 / lifecycle

The DevOps loop, and what I own in it

Eight stages, one continuous loop — the left lobe is delivery, the right lobe is operations, and feedback from the right feeds straight back into the left. Pick a stage to see the tooling and the work.

DevOps lifecycle loop DEV OPS Plan Code Build Test Release Deploy Operate Monitor

Stage 01 · Plan

Scope the change before touching prod

Requirements turn into an architecture decision and a rollback story — not a ticket that says "deploy it".

  • Capacity, cost and blast-radius modelled up front
  • Change windows, DR posture and compliance scope agreed
  • Git as the source of truth from day one
JiraGitArchitecture reviewCost modelling

click or tab through a stage on the loop

03 / engagements

What I've delivered, and what it was worth

Each one written the way I'd hand it over: the problem, what the investigation turned up, what got built, and the measurable result.

Problem
The client was paying for on-premise and legacy hosted capacity sized for a peak that almost never arrived — plus hardware refresh, licensing and a colocation bill that grew every year regardless of usage.
Investigation
Built a full inventory and took a 30-day utilisation baseline per workload. Most servers sat well under 20% CPU, several environments were idle outside business hours, and storage had years of data that had never been lifecycled.
Solution
Phased migration to AWS with a minimal-downtime cutover per workload — right-sized EC2 against real usage instead of legacy specs, managed databases, S3 lifecycle policies for cold data, scheduled shutdown of non-production, and reserved capacity committed only once the steady-state shape was proven.
Result
Roughly $10,000 removed from the annual run-rate, with capacity that now scales with demand instead of being bought ahead of it — and no hardware refresh cycle to fund.
Lesson
Don't buy reservations on day one. Migrate, measure the real shape of the workload for a month, then commit — otherwise you lock in the old over-provisioning at a discount.
AWS EC2RDSS3 LifecycleRight-sizingReserved InstancesCutover planning
Problem
The network line on the AWS bill was climbing faster than compute. Everything in the private subnets — S3 reads, ECR image pulls, CloudWatch Logs, Secrets Manager, STS — was being routed out through NAT gateways, paying an hourly charge and a per-GB data-processing charge on traffic that never needed to leave AWS.
Investigation
Broke the bill down by usage type in Cost Explorer to isolate NatGateway-Bytes, then used VPC Flow Logs to attribute that volume to specific destinations. Container image pulls and log shipping were the two largest contributors, and DNS resolution was adding avoidable lookups on top.
Solution
Deployed gateway endpoints for S3 and DynamoDB (no hourly cost, no per-GB processing) and interface endpoints for ECR, CloudWatch Logs, Secrets Manager and STS, with route tables and security groups updated so private subnets reach these services over the AWS backbone. Added Route 53 alias records to remove billed DNS lookups on internal hostnames.
Result
The bulk of NAT data-processing volume disappeared, and the traffic that remains is genuine internet egress. It was also a security win — image pulls and log shipping no longer traverse a public path, which simplified the compliance story.
Lesson
Cloud cost is usually an architecture problem wearing a billing costume. The NAT gateway wasn't expensive because of its price — it was expensive because traffic was taking the wrong path.
NAT gateway path versus VPC endpoint path BEFORE Private subnet app / ECS tasks NAT Gateway hourly + per-GB Internet GW public path S3 / ECR CW Logs AFTER Private subnet app / ECS tasks VPC Endpoint gateway + interface AWS backbone S3 / ECR CW Logs

Same destination, one fewer billed hop — and it never touches the public internet.

VPC EndpointsGateway & InterfaceNAT GatewayVPC Flow LogsRoute 53 aliasCost Explorer
Problem
Environments were built by hand from a runbook. Provisioning took days, every environment drifted from every other one, and "it works in staging" stopped being a meaningful statement.
Investigation
Timed the release end to end and mapped where it actually went. The build wasn't slow — the waiting was: manual approvals, hand-provisioned resources, and re-doing configuration that had drifted since the last deploy.
Solution
Rebuilt provisioning as reusable Terraform modules with remote S3 state and DynamoDB locking, layered Ansible for configuration, and wired both into a Jenkins pipeline so build, plan, apply and deploy run as one automated sequence rather than four handoffs.
Result
Deployment time down ~70% and provisioning time down by a similar margin against the manual process. Environments became reproducible — a new one is a variable file, not a two-day project.
Lesson
The slow part of a release is almost never the machine. It's the queue of humans waiting on each other.
TerraformRemote state + lockingAnsibleJenkinsGradleDocker
Problem
Releases were a person with SSH access, a build on a laptop and a checklist. Deploys happened out of hours because nobody trusted them, and there was no record of what shipped.
Investigation
Walked the existing release process step by step to find where the risk actually sat — untracked build artifacts, environment-specific rebuilds, and no gate between a bad commit and production.
Solution
Built end-to-end pipelines in Jenkins — multibranch builds through Gradle, Docker image build and push to Nexus/ECR, SonarQube and Trivy gates, then automated deploy to ECS/Kubernetes with Argo CD handling GitOps sync for the Kubernetes side.
Result
Releases moved from fully manual to fully automated, with the same artifact promoted across environments, a complete audit trail per deploy, and rollback by reverting a commit.
Lesson
A pipeline earns trust by being boring. Once the same button ships to every environment, out-of-hours deploys stop being necessary.
JenkinsGitLab CIArgo CDGitOpsNexusSonarQubeTrivy
Problem
Monitoring was scattered — CloudWatch for AWS, New Relic for the application, logs somewhere else, and no single view of whether the platform was actually healthy. During an incident, the first fifteen minutes went on opening tabs.
Investigation
Catalogued what each tool already collected and where the real gaps were. The data mostly existed; what was missing was correlation — nobody could line up an application error with the infrastructure event that caused it.
Solution
Built a central Grafana dashboard fed by Prometheus for metrics, ELK / OpenSearch for log aggregation and search, and CloudWatch and New Relic pulled in as additional data sources — so one view covers infrastructure, containers, application and logs. Defined SLA / SLO / SLI panels and routed alerts through Alertmanager to the people actually on call.
Result
Incident triage starts on one screen instead of five. Root-cause analysis using ELK/OpenSearch and CloudWatch Logs measurably reduced MTTR on critical incidents, and SLA/SLO reporting became something we could show, not estimate.
Lesson
More alerts is not more observability. The value is in correlation and in alerts that a human is willing to be woken up for.
PrometheusGrafanaELK StackOpenSearchCloudWatchNew RelicAlertmanagerSLO / SLI
Problem
Applications in AWS needed to reach systems that stayed on-premise — databases and partner-facing services that couldn't be exposed to the internet, but were being reached over ad-hoc public routes and allow-listed IPs.
Investigation
Mapped which flows genuinely needed on-prem reachability and audited the address plan. Overlapping CIDR ranges between the on-prem estate and the VPC had to be resolved before anything could be routed cleanly.
Solution
Established AWS Site-to-Site VPN with two IPsec tunnels to separate endpoints for redundancy, terminated on a Virtual Private Gateway / Transit Gateway, with BGP handling dynamic route exchange and failover. Re-planned the address space to remove overlap, then tightened route tables, security groups and NACLs so only the required flows crossed the tunnel.
Result
On-prem systems became reachable over an encrypted private path with automatic failover between tunnels, and the public allow-listing was retired.
Lesson
Sort out the IP address plan before you build the tunnel. Overlapping CIDRs are far more painful to fix after routing is live.
Site-to-Site VPNIPsecBGPVirtual Private GatewayTransit GatewayRoute tablesNACL / SG
Problem
Internet-based connectivity was good enough until it wasn't. Latency-sensitive integrations saw jitter and occasional packet loss at peak, and putting regulated traffic across a public path kept widening the compliance scope.
Investigation
Correlated the latency spikes against transit conditions rather than application load, and confirmed the variability was in the path, not the platform — which meant no amount of application tuning was going to fix it.
Solution
Worked with Tata Communications on the carrier side for the MPLS last-mile and cross-connect, and provisioned AWS Direct Connect with a private VIF into the VPC, BGP peering for route exchange, and the existing Site-to-Site VPN retained as a backup path so a circuit failure degrades rather than disconnects. Coordinated the LOA-CFA, cross-connect and BGP turn-up with the carrier and the colocation provider.
Result
Latency became predictable instead of merely usually-fine, sensitive traffic moved onto a private circuit and out of the public path, and the network had a real failover story rather than a single dependency on the internet.
Lesson
Carrier work runs on lead times, not sprints. Start the circuit order early and keep the VPN alive as the backup — the day the fibre gets cut, that decision is what saves you.
AWS Direct ConnectPrivate VIFMPLSTata CommunicationsBGPCross-connect / LOA-CFAVPN failover
Problem
Production sat entirely in a single AWS region. A regional event would have taken the whole platform with it, and the recovery plan was a document rather than an environment.
Investigation
Worked out which components genuinely needed replication versus which could be rebuilt on demand, and what it would take to keep the secondary from silently drifting out of sync with production.
Solution
Used Ansible-based provisioning alongside Terraform to replicate the AWS estate from Mumbai to Hyderabad, so the DR region is built from the same code as production rather than assembled by hand.
Result
A working disaster-recovery environment that is part of the standard operating posture — provisioned, verifiable and re-runnable, not a slide in a compliance pack.
Lesson
DR that isn't provisioned the same way as production will drift, and you'll find out on the worst possible day.
AnsibleTerraformMulti-regionap-south-1 / ap-south-2Runbooks

04 / services

How I can help

Cloud migration

On-prem or legacy hosting to AWS, with a minimal-downtime cutover and a bill that's smaller than the one you left.

CI/CD pipelines

Jenkins, GitLab CI and Argo CD — build, scan, promote and deploy without a human in the middle.

Infrastructure as code

Terraform modules and Ansible roles that make environments reproducible instead of artisanal.

Security & compliance

VAPT remediation, image hardening, PCI-DSS and RBI readiness — built into the pipeline, not bolted on.

Cost optimization

VPC endpoints, right-sizing, alias records and reserved capacity — cutting spend without cutting reliability.

Monitoring & SRE

Central Grafana dashboards, log aggregation, SLOs and alerting that respects the on-call rotation.

Hybrid networking

Site-to-Site VPN, Transit Gateway, Direct Connect and MPLS — private paths with real failover.

Production firefighting

Something is broken and nobody knows why. I trace it to root cause instead of restarting the pod.

05 / experience

Deploy log

Mar 2024 → present running

DevOps Engineer — Pay10, Delhi

  • Operated highly available production infrastructure on AWS (EC2, ECS, IAM, VPC, Route 53, ALB, API Gateway), sustaining 99.9% uptime via rolling, zero-downtime deployments.
  • Automated end-to-end CI/CD with Jenkins, Docker, Gradle and Terraform — moving releases from manual to fully automated and cutting deployment time by 70%.
  • Provisioned infrastructure as code with reusable Terraform modules and remote state, reducing provisioning time by 70% versus manual setup.
  • Cut network spend using VPC endpoints and Route 53 alias records, taking AWS-bound traffic off NAT gateways and removing billed DNS lookups.
  • Built centralised observability with Prometheus, Grafana, ELK, OpenSearch, CloudWatch and New Relic — sharpening SLA/SLO visibility.
  • Delivered hybrid connectivity: Site-to-Site VPN, and AWS Direct Connect with MPLS via Tata Communications for deterministic, private links.
  • Led incident response and RCA using ELK/OpenSearch and CloudWatch Logs, reducing MTTR on critical incidents.
  • Hardened Docker images with multi-stage builds, cutting image size by ~50%.
  • Ran Ansible-based provisioning and led DR implementation, replicating AWS infrastructure from Mumbai to Hyderabad.
  • Coordinated VA/PT remediation with Trivy and SonarQube, maintaining PCI-DSS / RBI compliance across Linux fleets.
Aug 2023 → Mar 2024 archived

DevOps Engineer, Contract — Freelance, Remote

  • Migrated on-premise databases and applications to AWS and Azure for 2–3 clients with minimal-downtime cutover strategies, removing roughly $10,000 of annual run-rate for one of them.
  • Cut AWS cloud spend by 20%+ through right-sizing, reserved capacity planning and eliminating unused resources.
  • Built Jenkins CI/CD pipelines from scratch, replacing manual releases and shortening release cycles.

06 / approach

Production doesn't wait for documentation.

Anyone can write a deployment script. The value is in what happens when that script fails at 2 a.m. My experience is in debugging real infrastructure under pressure — tracing an issue back to its root cause instead of restarting the pod and hoping. Then automating it so it can't happen the same way twice.

Identify→ Diagnose→ Fix→ Automate→ Prevent
Application connectivityDocker networking CrashLoopBackOffCI/CD failures Database connectivityAWS networkingLoad balancers API GatewayDNSCapacity Deployment failuresAlerting gapsCloud cost spikes BGP / routingIPsec tunnels

07 / stack

Service status

Cloud platforms

AWS EC2ECSIAMVPCRoute 53ALBAPI GatewayCloudWatchAuto ScalingAzure VMs

Networking

VPC EndpointsTransit GatewaySite-to-Site VPNDirect ConnectMPLSBGPIPsecNAT / IGWFlow LogsNACL / SG

Infrastructure as code

TerraformModular designRemote stateState lockingAnsible

Containers & orchestration

DockerKubernetesECSArgo CDGitOpsMulti-stage builds

CI / CD

JenkinsGitLab CIGitGitHubGradleNexusECR

Monitoring & observability

PrometheusGrafanaELK StackOpenSearchCloudWatchAlertmanagerNew RelicSLA / SLO / SLI

DevSecOps

TrivySonarQubeImage hardeningVA/PTPCI-DSSRBI complianceWazuh SIEM

SRE & reliability

Incident managementRCAHigh availabilityDisaster recoveryCapacity planningPerformance tuning

Scripting, OS & AI

BashPythonLinuxUbuntuAmazon LinuxLangChainVector DBsRAG

08 / projects

Systems built

GitOps Kubernetes deployment pipeline

operational

An Argo CD workflow that continuously syncs Kubernetes manifests from Git, so cluster state always matches what's declared — no manual drift, no surprise config.

  • Environment-based manifest layout (dev / staging / prod) with scripted image tagging that triggers auto-deployment.
  • Git as the single source of truth — instant rollback and a full audit trail of every deploy.
Argo CDKubernetesGitOpsCI/CD

RAG document Q&A system

2 months

A retrieval-augmented generation proof-of-concept using LangChain that answers natural-language questions grounded in uploaded PDF documents.

  • Ingestion pipeline chunking PDF content into overlapping segments for better retrieval.
  • Per-chunk embeddings stored in a vector database for fast semantic search.
  • Modular by design — embedding model, vector store and LLM provider each swappable.
LangChainVector DBEmbeddingsSemantic search

09 / certifications

Verified

  • AWS Certified Solutions Architect — Associate
  • AWS Certified Cloud Practitioner

10 / education

Foundation

B.Tech, Electronics & Communication Engineering

AISSMS Institute of Information Technology, Pune

2019 – 2023

11 / let's talk

Have a DevOps problem worth solving?

A one-off troubleshooting call, a cloud migration, CI/CD from scratch, a cost audit, hybrid connectivity, or ongoing DevOps support — tell me what's breaking or what's costing too much, and I'll tell you what it takes to fix it.

Discuss your project Email me directly

12 / contact

Let's build infrastructure that just works.

Freelance, consulting or full-time — my inbox is monitored.

Email sahilkoundalwork2002@gmail.com Phone +91 93077 39598 LinkedIn /in/sahil-k-8a81bb178 GitHub /sahilk020