Krishna Koushik Thokala

Operations-first cloud infrastructure

Krishna Koushik Thokala

Cloud Infrastructure Engineer

I build cloud infrastructure that is observable during failure, safe to change, and clear to hand off—combining hands-on AWS engineering with two years of production operations experience.

2 years production operations · AWS Solutions Architect – Associate · MS Computer Science

View selected projects → Download résumé ↓

About

For two years at Tata Communications, I worked on the side of infrastructure most people never see: 24/7 NOC rotations, night shifts, and high-severity incidents where a carrier circuit is down and everyone is waiting for a clear answer. I troubleshot BGP and MPLS failures, TCP/IP issues, DWDM optical faults, and 100G escalations. That work taught me to stay calm, isolate the fault, coordinate the right people, and restore service within the SLA.

It also changed how I think about systems. Once you’ve handled a high-severity incident at 2 AM, reliability stops being an abstract requirement. I don’t want to only react to failures; I want to build infrastructure so there are fewer of them—and so the next engineer on shift has the visibility, documentation, and recovery path they need.

During and after my MS in Computer Science at Indiana University Bloomington, I applied that same operations-first mindset to cloud infrastructure. My projects include an EKS reliability platform, a GitOps delivery platform, and a serverless uptime monitor. I build with observability, least-privilege access, recovery, cost awareness, and clear handoffs in mind—not as extras, but as part of the system from the beginning.

Projects

krishna310301/cloudops-sre-platformsource
EKS Reliability Platform dashboard showing service health, deployments, and incident timelines

EKS Reliability Platform

SRE · EKS · OBSERVABILITY

Measuring reliability the way users experience it, then proving the measurement

Built an AWS reliability platform that connects application health, Kubernetes deployments, scaling behaviour, alerts, and incident context in one operational workflow — then validated it against published evidence rather than screenshots.

Terraform provisions a 59-resource foundation across a tiered VPC, EKS, RDS PostgreSQL, ECR, Secrets Manager, and CloudWatch. Prometheus recording rules define availability and latency indicators, and every figure below is traceable to an artifact committed in the repository.

  • Availability SLIs scoped to user-facing routes, excluding health, metrics, and load-generation traffic, and counting only 5xx as failure so client validation errors are not recorded as downtime
  • Multi-window multi-burn-rate error-budget alerting against a 99.9% target — 14.4× fast burn paging, 6× slow burn ticketing — verified by 5 promtool test cases
  • Environment destroyed 54 minutes after apply, with closure confirmed across 14 checks and one tagging check recorded as inconclusive rather than passed
2 → 6 replicas18,819 requests0 failed requests
Amazon EKSTerraformHelmPrometheusCloudWatchk6RDS
View validation evidence → Source code ↗
krishna310301/cloudops-gitops-platformsource
Four Argo CD applications showing Synced and Healthy status on Amazon EKS

GitOps Delivery Platform

AWS VALIDATED · GITOPS · SUPPLY CHAIN

Auditable Kubernetes delivery where Git is the only way in

Built and validated an Amazon EKS delivery platform where Git controls application promotion, configuration, and rollback across dev, staging, prod, and observability namespaces.

Terraform composes the AWS foundation as 15 reusable modules under a $25 monthly budget guardrail. GitHub Actions authenticates through branch-scoped OIDC with no stored credentials, and Argo CD reconciles declared state into EKS.

  • Four-gate promotion pipeline: rejects any tag that is not a verified 12-character commit SHA, confirms the commit exists in Git and the image exists in ECR, and lands every promotion as a reviewable pull request
  • Per-namespace RBAC and ResourceQuotas across all four namespaces, with NetworkPolicies on the three application namespaces
  • Drift self-healing and Git-revert rollback validated on a live cluster by injecting a readiness failure and recovering through Git alone
15 Terraform modules4/4 apps healthyDrift + rollback validated
Amazon EKSArgo CDTerraformHelmGitHub ActionsOIDCPrometheus
View validation → Source code ↗
krishna310301/cloudops-uptime-monitorlive
Serverless Uptime Monitor dashboard showing live endpoint status

Serverless Uptime Monitor

SERVERLESS · LIVE · SECURITY

Detecting outages quickly without creating alert noise

A 53-resource serverless monitoring stack that checks endpoint availability, records status history, and alerts only when a monitored endpoint changes state. This one is deployed and running.

EventBridge schedules checks, Lambda performs validation, DynamoDB stores history under TTL retention with point-in-time recovery, SNS delivers notifications, and a CloudFront dashboard serves live state through Origin Access Control.

  • A dedicated latest-status access pattern so dashboard refreshes read 10 current rows instead of scanning 86,400 retained records, holding read cost flat as retention grows
  • SSRF defence rejecting loopback, private, link-local, and EC2 instance-metadata addresses, revalidating targets after DNS resolution before following redirects
  • Stateful alerting across UP→DOWN, DOWN→DOWN, and DOWN→UP transitions, so sustained outages do not page repeatedly while recovery still notifies
1s detection53 AWS resourcesZero duplicate alerts
AWS LambdaDynamoDBAPI GatewayEventBridgeCloudFrontKMSX-RayTerraform
View live project → Source code ↗

Experience

  1. Jul 2022 – Jul 2024

    Tata Communications

    Senior Engineer, Shift Lead
    • Led 5-engineer shifts in a 24/7 on-call NOC, owning triage and resolution of 40+ daily priority incidents across 25–30 Tier-1 carrier clients on global ILL, DWDM, submarine cable, and 100G transport infrastructure.
    • Diagnosed BGP and MPLS routing failures, TCP/IP connectivity faults, DWDM impairments, and hardware failures across Juniper, Huawei, Ciena, and Alcatel platforms.
    • Drove high-severity incident response end to end, coordinating vendor TAC engagement, field dispatch, and customer-premises testing through to service restoration.
    • Prioritized concurrent P1 and P2 incidents in ServiceNow against 99.9% availability and 4-hour restoration commitments, maintaining direct customer communication throughout active outages.
    • Authored post-incident RCAs and structured shift handoffs that preserved troubleshooting context across rotations; earned a Certificate of Excellence for resolving an escalated incident into a documented customer win.

Skills

I pick up tools by building something real with them, then trying to break it. This is what I’ve actually shipped — the projects above are where the detail lives.

AWS
EC2VPCEKSECRLambdaAPI GatewayRDSDynamoDBS3CloudFrontSNSEventBridgeKMSSecrets ManagerIAMCloudWatch
Infrastructure & delivery
TerraformKubernetesHelmArgo CDDockerGitHub ActionsCheckov
Observability & reliability
PrometheusGrafanaCloudWatchSLIsBurn-rate alertingHPAk6Incident responseRCARunbooks
Languages & systems
PythonBashSQLPostgreSQLLinuxGitFastAPIReact
From the network side
BGPMPLSDWDMTCP/IPDNSRoutingFirewallsServiceNow

Education

  1. Aug 2024 – May 2026

    Indiana University Bloomington

    MS, Computer Science

    Went deeper into the systems and cloud side of the work I’d spent years operating.

  2. Jun 2018 – Jun 2022

    SRM Institute of Science and Technology

    B.Tech, Computer Science & Engineering

    Where the interest in how systems actually work started.

Resume

A one-page version — easy to skim or share.

Download one-page résumé (PDF)